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Abstract 

The decentralization of admirdstratb^e systems at Virginia Polytechnic Institute and State 
University has evolved both by design and by virtue of advances in technology and :iser 
expertise. Meanwhile, forces both external and internal to the University have focused 
attention on the need for minimum leveb of standardization in order to utilize the various 
information resources to the institution's best advantage. In response to these pressures, the 
offices of Institutional Research and Data Administration (later renamed Irtformation 
Resource Management) undertook a project that resulted in the development of a set of 
guidelines for Irformation resource management. 

This paper describes the historical evobition of the present situation, the farces that motivated 
the development of the guidelines, and the consensus-bulldlng activities that led to the 
acceptance of the guidelines as University policy. Noted in particular are: the key role 
played by an existing loosefy-structured organization of systems coordinators; the bottom-up 
strategy for endorsement of the guidelines; and the management focus of the guidelines 
document. Insights gained along the way are presented to help those pursuing a similar 
e/uieavor. 
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Background I^fi^/mation 

Virginia Polytechnic Institute and State University, also knov^Ti as Virginia Tech. is the land-grant 
university of the G>mmonwealth of Virginia. With almost 25.000 students and over 1.500 full-time 
instructional facidty members. Virginia Tech is the largest university in the state. It ranks in the top fifty 
U.S. universities in total research expenditures, with an annual total approaching SI 00 million. Virginia 
Tech's computing capability includes an IBM 3090 Model 200 supercomputer* an IBM 3084. and several 
smaller mainframes. Access to the mainframes is provided by the 3.000 terminals across campus^ as well 
as by many of the 12.000 personal computers on campus. 

The Historical Evolution from a Centralized to a Decentralized Environment 

During the late 1960's and much of the 1970'8. administrative information systems at Virpnia Tech 
operated in a highly centralized environment, based on common methods, repetitive procedures, and shared 
knowledge withm a small group of ei^rts. Essentially all major recoid-keeping systems were IMS systems 
developed in house by the central Systems Development office. This crntraiization offered the braefit of 
consistency ac .ss systems, along with the potential for large-scale integration. The level of expertise 
required to develop and mamtain IMS applications also encouraged the maintenance of a central support 
system. Requirements for integration and security across systems and Uie sharing of limited mainframe 
computing resources led to a "build-on"" approach to existing systems and furthered the need for coordinated 
and centralized data-base management. 

Counterbalancing the forces promoting centralization were policies and decisions that led to the 
distribution of data management activities. Principal among these was the fact that central operational data 
systems were never operated as a 'job-shop''. Virginia Tech never intended to maintain a central pool of 
progranuners providing support to administrative units who needed access to University data. Instead, the 
practice was for in-house-developed systems to be turned over to user offices (along with the addition of 
some support staff positions) for kx^al management and maintenance of production systems. All major 
production applications wtt run by decentralized system-coordinating groups. On a somewhat informal 
basis. Systems Development staff provided continuing backup support for trouble shooting and minor 
modifications on the systems they developed. The central Data Adimnistration office administered the IMS 
data base system and the UCC-10 data dictionary that supports IMS, coordinate and assist^ with 
production implementation, managed security, controlled IMS space allocations, and maintained a system 
of shared tables. 

During the 1980's, the move toward decentralization accelerated dramatically. Programming and 
systems-analysis staffs were growing in administrative offices across the campus, especially in support of the 
student, persoimel/payroU. and accounting record systems, but also on a snlailer scale in a number of other 
offices. While the I adget of the computing center remained a central allocation of real doUars controlled 
by the use of allocations of computer dollars, the other costs associated with such staff growth — salaries, 
equipment, supplies, professional development, etc. ^ were direct costs in the budgets of the individual 
offices. This shift in dollars promoied a corresponding shift in the mindset of ^e managers of the admin- 
istrative units, a shift toward a muc'i more decentralized point of view. 'If it's MY money being spent, then 
rd like more control on how it's s;?ent/ summarizes this new perspective. 

Software developments played a role in the move toward decentralization, as new less-complicated 
data-management systems and languages such as SPIRES® ^ F0CUS®3. and SAS®^ allowed operating 



1 SPIRES is a registered trademark of Stanford University, Stanford. CA 

3 FOCUS i- a registered trademark of Information Builders Inc.. New York, NY 10001 

3 SAS is a registered trademark of SAS Institute Inc.. Gary. NC 2751 1 
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offices increased independence from central support systems. Fourth-generation languages were eagerly 
CAamined by both the central computing-support offices and by the operating offices as potential new tools 
for maintainmg systems and providing services. For the first time, the purchase of sophisticated off-the-shelf 
software packages began to be considered as a serious alternative to developing all major systems in house. 

The Motivating Forces in thje Development of Guidelines 

Tht development of guidelines for information resource managonent at Virginia Tech should be 
viewed against the backgroimd of a number of campus events, trends, and initiatives of the latter half of the 
1980's. A major force was the rapid expansion in the number of personal computers on campus, including 
many that were bought by administrative units that had never been heavy users of mainframe computing. 
Suddenly, offices that had no previous capability for using administrative data in unprocessv^ forai were 
displaying appetites for data that were commensurate with their rapidly developing skills in word processing, 
graphics packages, spreadsheets, and data bases. 

Another major contribution came from the University Self Study of 1986-88, which identified several 
concerns in the area of information resource management, including documentation, consistency of coding, 
and ease of access. Specifically, the self-study report contained the following points. 

• A recommendation for an inventory of the data bases used for management information, and for the 
development of procedures for consistent coding, complete documentation, user training, and system 
mtegration. 

• A suggestion that the office of Data Administration (which was later lenamed Information Resource 
Management) take a lead role in the coordination, integration, and dissemination of the new wave of 
mfonnation technology. 

• A recognition of Institutional Research as a major player in the process of gathering and analyzing data 
to support the planning and decision-making functions. 

A concurrent campus initiative was the commitment to move toward a 'Single System Image'' (SSI), 
a vision being articulated by Dr. Robert Heterick, Vice President for Inforaiation Systems. (See 'A Single 
S/stem Image: An Information Systems Strategy', CAUSE Professional Paper Seres, #1, May, 1988.) 
This vision accepts the increased pluralism of 'native computing environments' — whether mainframe, 
minicomputer, or microcomputer, and .vhether spreadsheet, word processor, data Use, or other - and 
develops a strattgy for maintaining 'coherency in computing and communicatfons'. In the context of 
administraUve information systems, the SSI implies the capability of moving large amounts of diverse input 
and output to and from a variety of native environments. Essential to this transmission process is the 
estabhshment of standard interfaces, based upon intelligent data-management systems capable of doing the 
required translation. 

Another motivating factor was the emergence of external standards, such as the International Standards 
Or^nization's Open Systems Interconnect (ISO/OSI) model for data coiamuaications and the American 
National Standards Institute's (ANSI) Information Resource Dictionary Systems (IRDS) standard, 
approved m 1988. Meanwhile the University began to witness growing acceptance of 'standard electronic 
operatmg pr x:edures' for particular business function' in the private sector where the University conducts 
busmess. Ai a prime example, vendora were positioning themselves to accept purchase orders using 
Electronic Dita Interchange (EDI) standards. In order for Virginia Tech to anticipate, plan, and be 
responsive to these initiatives and reap the accompanying benefits, it was clear that some degree of 
conformance to standard practices for data management was imperative across the University's infonnation 
resources. 

The Self Study played another significant role in the move toward guidelines through its call — together 
v-ith the Umversity's positive response to the caU - for the development of a stratepc planning process. 
It was generally recognized that (a) such a process could place major new demands on administrative data 
systems to provide management information to support plarming and (b) the ability of the University's 
decentralized data systems to provide the integrated data needed by such a process was suspect. 
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The problems inherent Jn on^ area of the administrative data systems — but symptomatic cf problems 
m a nimiber of other areas — were highlighted in the work of the Facilities Data Base Task Force, which 
completed its six-month study in September of 1988. The task force found a proliferation of special- 
purpose systems operating totally independently of one another, using imprecise or corilicting data 
definitions, and offering very few options for sharing of information. The task force's report identified 
several essential standards for data quality and usefulness including rigorous definitions, standardization of 
data items, uniform sets of codes, and documentation of data elements and structures. 

Another motivating factor in the development of guidelines, itself a consequence of some of the forces 
described above, was the start of planning for a data dictionary. Data Administration was charged with 
looking at the products available commercially and the possibility of developing a data dictionary in house. 
The immediate goal was to provide a tool tor the inventory and documentation of the entire administrative 
data resource. The ultimate goal was the development of a ""university data base', a concept that had earlier 
been articulated in a position paper developed by Data Administration. In general terms, the un-^ersity data 
base is a lo^cal data base (not necessarily a physical data base) which provides a stable information archi- 
tecture within which the authorized users of University information can obtain what they need to peiiorm 
their duties. 

A final event worth noting is the 1986 decision to purchase an accounting system to replace the 
IMS-based accounting system that was nearly twenty years bid. This decision was made at a time *vhen the 
resources of Systems I>evelopment were heavi'y committed to developing a new tudent system in IMS. 
The student-systems project had an inmiovable taiget date of Summer 1988, at which time the University 
would convert from a quarter to semester system. A decision to develop the accounting system in house 
would have meant several years delay in implementation. 

Nonetheless, the decision to purchase the accountiiig system sent shock waves throughout the 
University administration, both for being the first commercial software package to be used for a major 
operational system, and for net being an IMS system. Unforeseen problems, delays, and expense also 
created a few aftershocks. Th^, magnitude of the effort required to configure the new ''ystem to the 
Universit/s computing environment raised the consciousness of the University's executive leadership about 
the need for communication between and consistency across data systems and about the associated costs 
when consistency is lacking. 

The Development Process 

The process of developing guidelines for information resource management began in Spring 1988 with 
meetings of a core group consisting of two representatives from Data Administration and two represen- 
tatives from Institutional Research. These meetings had multiple agenda items. Both units wanted to 
define and develop their positions relative to the Self-St^dy mandates. Institutional Research represen- 
tatives were anxious to talk about issues of consistency and communication among administrative data 
bases, as a consequence of both their traditional responsibility for data-gathering and reporting projects that 
involve multiple data bases and their prospective new role in support of the planning process. Data 
Administration representatives wanted to begin their feasibility study on data dictionaries and to define their 
long-term role in the development of a 'university data base*. In this connection, they wanted to discuss 
the possibility of using Institutional Research's Student Census File as a starting point. 

Early in the discussions, a common thread among all of the agenda items became clearly evident: the 
need for guidelines and standards in the management of all of the University's administrative data systems. 
It also became clear that a fairly distinct division could be made between guidelines and standards, in the 
sense that guidelines indicate what should be done and standards indicate how it should be done. It was 
quickly recognized that ihe issue of standards, with its attendant enforcement questions and other political 
problems, had the potential for derailing the entire process. Everyone in the core group agreed to put aside 
standards for the moment and to focus first on guidelines. 

Balkan/Sheldon 3 CAUSE89 



ERIC 



7 



Developing GuideUnet for Informuion Retource Management 



«!. ^J^^ *^ of guidelines wm drafted m August 1988. However, the group recognized that, without 
the perspective and the support of the individuals who operate and maintain the individual administrative 
data ^ems, these or any other set of guidelines had no future. 

The next step involved the Administrative Systems Users' Group (ASUG), a loosely-structured 
organization open to all mterested parties. The intent of ASUG is to provide an open fonim for commu- 
nication between central computmg-support offices (Systems Programming, System? Development, Data 
Administration, User Services, etc.), system coordinating offices (Accounting Student Systems, etc.), and 
other users (Inrtitutional Research, Budget a'.d Financial Planning, Extension Information Systems, 
Library, etc.). ASUG s monthly meetmgs include time for announcements of general interest and questions 
oa topics of common concern. Despite its informal basis and its lack of any official status in the University 
admmistrative structure, ASUG has made productive contributions to the University beyond just serving 
Its conunumcation function. Since its inception in 1986, one ASUG subgroup has developed COBOL 
programming standards and another provided significant input on requirements for an access-control 
software package that was purchased in 1988. In both cases, the proposals from these ASUG committees 
were presented to ASUG as a whole where they were reviewed, modified, and endorsed. 

In July 1988, five individuals were asked to represent ASUG on a committee tc assist in the develop- 
meat of guidelines. Four of the individuals were from the staff - generally senior programmer-analysts - 
ot toe offices of Student Systems, Accounting, Facilities, and Budget. The fifth member was the EDP 
Auditing Manager from Internal Auditing. Two from the core group were also commiti?? members and 
coordinated the group meetmgs. 

The conuiutte* members were encouraged to reach their own conclusions, with little pressure to retain 
the features of the draft document prepared by the core group. After a series of meetings over a period of 
three months, characteiized by a lot of thought-provoking discussion and a considerable sense of give and 
take, a guideliiws document was fmished. The document was basically a revision of the original draft of the 
core group, refined by the management perspective of the ASUG representatives. In the tnie spirit of 
compromise, no mdmdual on the committee thought that the guidelines were exactly what he or she 
wanted, but they all agreed that they had a chance to be heard in the deliberations and were willing to 
support the document, both m ASUG and within their own offices. Perhaps the greatest concern expressed 
by the committee members was that they might be percHved as telling their own managers how information 
systems should be managed. 

The revised set of the guidelines was distributed at the November meeting of ASUG, along with a 
request for comments and suggestions. It was announced that the guidelines would be on the asenda of the 
January meetmg. " 

• 1 P"™*8 December, a meeting was held for the managers of the various administrative data systems, 
mcluding the unmediate supervisors of several of the committee members. These individuals, basically the 
most semor among the ASUG members, were considered essential to building the consensus needed at the 
operational level. The group suggested some improvements in wording and other clarifying statements, and 
without a formal vote, generally endorsed the document. 

• 1 the January ASUG meeting, a representative of the core group led discussion on the guidelines, 
mcluduig the proposed changes incorporated into the document as a result of the December meeting. 
Among the pomts that came out in the discussion were these: 

• The guidelines must be viewed as a living document; revisions will continue to be made as consensus 
dictates. 

• Many of the 'data custodians' (generally the individuals to whom the systems managers report) are 
not currently aware of their responsibilities as set forth in the guidelines. An important function that 
should not be overlooked is that of educating and assisting the data custodians. 

• Data Admiiustration must move toward standardized interfaces and security strategies for decentralized 
systems and provide tools such as a comprehensive data dictionary for information-resource 
documentation and reference. 
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• Some of the tasks implied by the guidelines are not currently being done. To accomplish them, 
additional resources (for example, documenUttion specialists) and/or new strategies will likely be 
required. 

• Clarifications of responsibility and authority may be needed to ensure that the guidelines are followed. 
In particular, the need for clear responsibilities for data-exchange interfaces in the evolving distributed 
environment was noted. 

The discussion concluded with an endorsement of the guidelines. 

Also in January of 1989, the core group initiated discussions with the Assistant Vice President for 
Administrative Affairs, whose responsibilities include two that are directly relevant to the guidelines project. 
One is the ADMINSYS system, an on-line repository and reference system for University policies and 
procedures. The second is the office of Records Management, which was in the process of developing local 
records-management policies and procedures to conform with Virginia's state policy. Initial discussions 
focused on how electronic records fit mto a policy which — although it refers to Information in any 
recording medium including data processing devices and computers' — is definitely oriented to hard-copy 
records. While the endorsed guidelines do not specifically address procedural issues for electronic recorxk 
management, they do provide a fi:amework for determining such procedural issues. Since standards and 
procedures would be devebped based on the guidelines, it was agreed that the guidelines belonged in the 
ADMINSYS system, with cross references to other sections of records management policy. 

In March 1989, the guidelines document was presented to all those administrators who have respon- 
sibility for the major operational data systems. These are the individuals called the ''data custodians'" in the 
guidelines. They have titles like Controller, Associate Provost for Student Systems, and Associate \^ce 
President for Facilities. Generally speaking, they hold positions just under the vice-presidential level and 
just above the level of the ASUG members. AU of these individuals were provid^ with copies of the 
guidelines and invited to attend a meeting to discuss thein. Again after only minor modification, the ''data 
custodian^ group endorsed the guidelines. 

It is worth noting that in each meeting with the various constituenc> groups questions were raised 
regarding how the guidelines would be implemented or enforced. Although such lines of questioning arc 
clearly relevant and miportant, the gioup was encouraged to focus only on the principles (the what) now. 
It was made clear that the standards and procedures that would later be developed to conform with the 
guidelines would again progress through consensus-building forums. It was encouraging that the concepts 
embodied in the guidelines were viewed as both reasonable and needed at all levels of the organization. In 
fact, in response to a question about auditing and compliance, a representative of Internal Auditing 
suggested that he would routinely use this policy in his review process. 

In the final step of this informal 'approval' process, the Director of Institutional Research and the Vice 
President for Information Systems (the executive-level supervisors of the members of the core group and 
the two top-level individuals most directly responsible for carrying out the Self-Study mandates on data 
management) met and discussed the guidelines. These two agreed that the guidelines were appropriate and 
authorized their inclusion in the ADMINSYS system. 

Of course, this is not the end of the story. Much work lies ahead, most notably the development of 
standards. On the software side, the guidelines cleariy identify the need for data-management tools to help 
with issues of accessibility and compatibility, and they specifically mention the essential role of a central data 
dictionary. Development work is currently underway on a dictionary product which will run in a relational 
environment and which is based on the ANSI IRDS standard. Acceptance of these guidelines is an 
important first step for successful implementation of this data dictionary. 
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Strengths of the guidelines 

Perfiaps the most notable strength of the guidelines, and also a key to the broad base of endorseracnt. 
IS their management focus, as opposed to a technical or operational focus. Nontechnical, nonthreatening 
terminology was used intentionally to promote shared understanding. 

A second important strength of tht guidelines is that the criteria for inclusion of a data base or data 
clement undar the guidelines is based on the University's usage of information and not on existing system 
structures. The guidehnes mtroduce a concept called the Administrative University Data Base (AUDB), 
which is defined as a logical aggregate of data critical to the administration of the University. The ciiteria 
for mclusion m the AUDB cover all of the following classes of data. 

• Data rdevant to planning, managing, operating, or auditing major administrative functions. 

• Data referenced or required for use by more than one organizational unit. 

• Data included in an official University administrative report. 

• Data used to derive an element that meets the above criteria. 

Finally, the guidelines are strengthened by their definition of information management roles based on 
Iwiction, without regard to current or future organizational structure. This gives them general applicability 
which wUl not become obsolete m an environment of ever-widening distribution and ever-increasing use 
ol admmislratove information. Data custodians are ultimately responsible for the data created and referenced 
withm thor partiaUar area of responsibility and in turn, for conformance to the guidelines. Data stewards 
are those delegated the responsibility for data maintenance and dissemination as directed by data custodians. 
Individuals who have need for Umversity data are considered the data users. Virginia Tech is considered 
the data owner of all Umvcraty admmistrative data. The function of applying formal guidelines and tools 
to manage the Univeraty s information resource is tcmed data administration and is a role overseen by data 
custodians, but played by aU participants. The recent reorganization and rename of Infonnation Resource 
Man^ement (formerly Data Administration) underscores the leadership and support role this office 
provides for the distributed data administration activities. 

Also a crwUt to the guidelines is their breadth. FoUowing the introduction of the AUDB concept and 
explanation of the information management roles, they deal independently with each of the following topics- 
data capture; data storage; data validation and correction; data manipulation, modification, and reporting- 
data security, data documentation, and data avaUability. Next, they address the need and procedure for 
annual review with possible update, reference related poUcies, and end with a section defining terms used 
throughout. ^ 

Lessons Learned 

This final section presents some of the lessons learned by the core group as they progressed through 
the various steps m the development of the guidelines. Perhaps some of the insights gained along the way 
can be braeficial to oUiers and - if mcorporated into an initial strategy - serve to speed up this kind of 
process. The intent on this campus is to use a similar strategy in the process of establishing standards and 
procedures for conformance to the guidelines. 

Perhaps the most important lesson leamed and a primiiry point of success so far was the use of 
informal groups in the absence of formal organizational structures in the University community. Such 
groups generally brought to the process a set of diverse backgiounds and experiences, but were always able 
to identify common purposes and needs. Three of the key groups in this process - the core group, the 
system managers, and the data custodians - had never previously met together on a formal basis. 

Even ASUG, the most sti-ucturcd of the participating groups, has no officially recognized role in the 
admimsti»tion of the University. However, its choice as the first constituency group to work on the 
guidehnes was particularly successful. It had a history of working on common problems in an atmosphere 
of mutual trust. Moreover, its members were the people who would be affc ncd by the guidelines on a daily 
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banis, as well as tlie individuals whom the data custodians would consult about whether the guidelines were 
relevant and worthwhile. Getting this group's participation and endorsement as a first step turned out to 
be an excellent strategy. 

Also contributing to the success of the process was the riding of the tides that were surging in the 
University conununity. The case for guidelines was built on a biX)ad base of forces and events: the Self- 
Study, the purchase of an accounting package, the need for policy on records management, and several 
others. By capitalizing on the diverse array of motivating factors, the core group was able to convince a 
number of groups and University officials at various levels in the organization of the value of these guide- 
lines. 

Another lesson to be extracted fix)m this process is the importance of creating focus as a means of 
avoi(ting unnecessary controversy and distraction. This was the reason why standards were put aside 
initially in order to build consensus on guidelines. DcOate and discussion could be focused on tlus limited 
topic in order to build a foundation upon which to base further work and more attention to entail. 

As in so many projects, one of the keys was to maintain reasonable expectations. This was important 
in at least two areas. First, it was recognized by the core group and articulated to the constituency groups 
that neither totd agreement nor the perfect document were likely outcomes. Consensus, however, was 
attainable, even though no oi?e who contributed to this process was likely to agree with every point in the 
fmal document. Second, it was evident at every step of iht way that the process was and will continue to 
H an evolutionary one. The document ^s not "cast in stone', but is expected to continue to evolve in 
response to technological and environmi il change. 

The virtue of patience was yet another basic principle that was reinforced by the process of developing 
the guidelines. At each stage of the process, the guidelines changed slightly, as each new constituency group 
brought its new perspective into the discussion. From looking at the end result, it is evident that what 
seemed like minor modifications in fact served to build depth into the final set of guidelines. In retrospect, 
it seems unlikely that a top-down approach (which was the core group's first impulse) or any other less 
patient course of action would have worked as well. 

The final point to be made here is peihaps a capsule summary of the entire process. By acknowledging 
and illustrating data management problems without laying blame, by describing desired outcomes and 
suggesting a path for achieving those outcomes, the core group helped to expand thinking beyond the limits 
of individual turf boundaries or existing organizational structures. As a result, the Guidelines for University 
Administrative Information Resource Management arc not the 'rules according to XYZ Department', but 
rather a platform that will support a variety of idiosyncratic architectures and individual missions and, at 
the same time, support the global information needs of the University. 
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APPENDIX 

Virginia Polytechnic Institute and State University Policy and Procedures Section 2005 
Guid€luusfor UmtnUy Adnunisfratbt Information Rosowco Manngomoni 

1.0 Purpone 

While all administrative data captured using University assets are resources of the University, they vary in their 
rdevance to the administrauve processes of the University. This poUcy is intended to apply to those data which are 
critical to the administrauon of the University. WhUe these data may . esHe in different data ^ase management systems 
and on difTcrwit machines, these data in aggregate may be thought of as forming a logical data base, which will herein 
be caUed the Administrative University Data Base (AUDB). This terminology is not intended to imply that these data 
now or in the Aiture should reside in a single physical data base. Rather, it is a recognition that regardless of where 
these data reside, there are some g^eral pnnciples of data management that should be applied in order to maintain 
the value and guarantee effective use of the information resource. 

2.0 Policy 

2.1 Information Management Roles 

• The University is considered the data owner of all University administrative data. 

• ^n|y«wity officials, such as the Controller, the Associate Vice President for Personnd Resources, and the 
Registrar, are responsible for data in their functional areas and are considered daU custodians. 

• Staff delegated the responsibUity for information management activities related to maintenance and disseminaUon 
of data are considered data stewards. 

• Individuals who have need for University data in order to perform their assigned dudes and are therefore 
authorized access are considered data users« 

• Tht function of applying formal guidelines and tools to manage the University's information resource is termed 
data administration. Those data administration activities that do not fall within the realm of responsibiHty of 
designated data custodians are the responsibiUty of the Information Resource Management (IRM) department 

2.2 Data Included in the AUDB 

• A data element is considered part of the AUDB and should conform to AUDB standards if it satisfies one or 
more the following criteria: 

• It is relevant to planning, managing, operating, or auditing major administrative functions. 

■ It IS referenced or required for use by more than one orgcnizat«onat unit Data elements used internally 
by a single department or office are not ^ically part of the AUDB. 

■ It is included in an official University administrative report 

■ It is used to derive an element that meets the criteria above. 

• Data elements which meet the criteria for mclusion may be identifi^ as such by a data custodian, a data steward, 
IRM, or a user group. 

• A data custodian should be identified for each data element to be included in the AUDB. 

• IRM should assist in the negotiations for inclusion and for identification of data custodians. 

23 Data Capture 

• The data custodian is responsible for complete, accurate, valid, and timely data capture. These responsibilities 
may be delegated to data stewards. 

• Electronic daU should be captured at or near its creation point as identified by the data custodian. 

2.4 Datastorage 

• An official data storage location for each data element should be identified by the data custodian. 

• A official daU storage location of valid codes and values for each data element should be identified by the data 
custodian. 

• Data element names, formats, and codes should be consistent with University standards. 

• Archiving requirements and strategies for storing historical data should be determined for each data element by 
the data custodian. 

• IRM should assist in determining data storage location and archiving requirements for AUDB data. 
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2«S Data Validation Correction 

• Application^ that capture and update AUDB data should incorporate edit and validation checks to assure the 
accuracy of the data. 

• The accuracy of any element can be questioned by any authorized data user. The data user has the responsibility 
to help correct the problem by supplying as much detailed information as available. 

• The data custodian or delegated data steward i responsible for responding to questions and correcting incon- 
sistencies if necessary. 

• Upon Arritten identification and notification of erroneous data, corrective measures should be taken as soon as 
possible or in accordance with the consensus of the users to: 

■ Correct the cause of the erroneous data. 

■ Correct the data in the official data storage location. 

■ Notify users who have received or accessed erroneous data. 

2.6 Data Manipulation, Modification, and Reporting 

• The data custodian is responsible for authorizing manipulation, modification, or reporting of AUDB data 
elements and for creating derived elements, which are also members of the AUDB. 

• The data custodian is responsible for ensuring that data maintained are consistent with ofiicial University 
reporting requirements. 

• The data custodian has ultimate responsibility for proper use of AUDB data; individual data users will be held 
accountable for thdr specific uses of the data. 

• All extracted or reported AUDB records should include the time and date of data capture. 

2.7 Data Security 

• All A U Do data should be secured and access granted to a data user only for University business on a 
'^need-to-know*' basis and within predefined access rules and security requirements. 

• The data custodian has ultimate responsibility for determining security requirements and '\uthorizing access. 

• The individuals oi ofiice responsible for implementing access control will be identified and charged vnth this 
responsibility in writing by the data custodian. 

• The data custOilia«) is responsible for documenting authorization procedures. 

• llie data custodian is responsible for monitoring and revie>mng security implementation and authorized access. 

• All data users of AUDB data should sign a statement indicating thrir understanding of the level of access 
provided and their responsibility to likewise maintain the inherent privacy, accessibility, and integrity of the data 
th^ are ;^ro\aded. 

• Ihe data custodian is responsible for assuring that data are backed up and recoverable \u response to events that 
compromise data integrity such as system failure, inadvertent faulty manipulation, unauthorized user penetration, 
or other unforeseen disasters. 

2M Data Documentation 

• Documentation of data elements should be provided to IRM in machine*readable format and will reside *n a 
University Data Resource Dictionary. 

• IRM is responsible for the data administration function of maintaining the University Data Resource Dictionary 
and for middng it readily accessible to data custodians, data stewards, and data users. In essence, IRM is data 
custodian for the the Urdversity Data Resource Dictionary. 

• Documentation of data elen lents is the ultimate responsibility of the data custodian. 

• Documentation/definition ff r each data element should at least include: 

■ Name and Alias Nam :s 

■ Description 

■ Data Custodian 

■ Usage BD'l Relationships 

■ Frequency of Update 

■ Source for Data Capture 

■ Ofllcial DaU Storage Location and Format 

■ Description of Validation Criteria and/or Edit Checks 

■ L »cription» Meaning, and Location of Allowable Codes 

■ AoceM Rules and Security Requiremento 

■ Archiving Requirements 

■ Data Storage Location of Extracts 

• DocumenUtlon for derived AUDB data elements should include the algorithms or decision rules for the deriva- 
tion. 
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• Change in any of these characteristics diould be noted to IRM and/or recorded in the University Data Resource 
Dictionafy in advance oftlie change. 

2.9 DaU Availability 

• Data Custodians are responsible for providing accessible, mc9 Ingful, and timely machine-readable AUDB data 
for University use. This activity may be assigned to data st^ards or to other University officials within the 

E redefined access rules and authorization procedures. 
)ata custodians and IRM share responsibility for AUDB data compatibility, accessibility, and interfaces. 



3.0 Proceduret 



These GMftitm for UmnnUy Admimstmtbit InfovmatloH Resource Managmemt have been prepared by the 
InformaUon Resource Management (IRM) department and the Office of Institutional Research and Planning Analysis 
in association with Oie Administrative Systems Users Group (ASUG). They serve as a statement of objectives to 
manage the administrative information resource. These Guideimes apply to all AUDB data. In addition, these 
Guidelims should be considered and followed where possible by all those who capture data and manage administrative 
information systems using assets of tht University, Standards and prpcedurts should bo dowoloped to conform to tho 
okitctbos ombodkd in thaso Giddelinas, 

Copies of these GmdtUtms or releted standards documenU are available from the Information Resource 
Management Department and from the Administrative Information System. 

3.1 Updates 

As an ongoing document, these GuidoUnas for Unhmity Admimstratho Information Rosource Managamant will 
**!f/[!™5f"^^ revised as needed by the Information Resource Management department (IRM) in cooperation 
with data custodians and administrative systems users groups. All administrative system users are encouraged to 
correspond with IRM describing any suggestions for improving these Guidoiinas. When corresponding plear refer 
to the document title and provide an appropriate section and page number reference. 

Qiengfjs or updates to these GmdoUnos will be reviewed by the Agency Records Administrator to ensure 
conraphauce with Managemeni ofUnhorsity Records (University Policy 2000) and related State regulations. Revisix>ns 
to th^e Giddolms wiU be sent to the manager of the Administrative InformaUon System (before the effective date of 
Uie change, if possible). The update will be made, the date and revision number changed and the revision noted in 
Section 6.0, and returned to be approved and released. 

4.0 Definitions 

1. AUDB (Administrathre University Data Base) is a conceptual term used to identify that body of <!ata critical to 

University |)lanning, management and business operations. 
2 Data administration is the function of applying formal guidelines and tools to manage the University's information 

resource. 

3. Data custodians are the University offidals responsible for managing a segment of the Univenity's information 
resource. 

4. Data stewards are staff members delegated the responsibility for data maintenance and data dissemination. 

5. Data users are individuals who are authorized access to University data required by them to perform their 
assigned duties. 

6. University DaU Resource Dictionary is a database system that functions as a repository that contains compre- 
hensive mformation about Univenity dfta and documenution of University administrative systems. 

5.0 Referen»~es 

1. Poiicy WOP ''Management of Univenity Records,*" effective February 1989. 
6.0 Approvato and Revisions 

Approved January 5, 1989 by the Administrative Systems Users Group (ASUG). 
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Establishing and Implementing Policies and Procedures 
for End User Training in Higher Education 

Anne Knight 
Office for Information Technology 
Harvard University 
Cambridge, MA 

Elaine Q)usins 
Q)mputing Center User Services 
University of Michigan 
Ann Arbor, MI 



ABSTRACT 



At some institutions the central administration mandates or facilitates the use of 
technology for administrative, instructiraal, and research needs. At other 
institutions it is the office staff and faculty who, by using it, have discovered the 
value of technology; in these institutions, support is informal. Those who facilitate 
access to technology usually acknowledge and eenendly support training for staff 
and faculty with fund? and pCTSonnel. When access to technology is not actively 
supported, training is often ad hoc or obtained from sources both outside and inside 
the institution, usually for a fee. 

Haiyard University and the University of Michigan represent two contrasting, 
institutional models in the way they support technology. One applies a 
decentralized approach to user support, while the other is centrally supr^ jncd. 

Training is an aspect of user support tJiat often receives short shrift: it is under 
valued and under funded by administration at many institutions. At Harvard, 
training, like all user services, is provided both centrally and de-centrally, and is not 
consistently supported within the various Schools. Harvard's Office for 
Information Technology provides training open to all University employees, yet it 
is based on a fee-for-service. In contrast, at the University of Michigan, the 
Computer Center User Services provides free training to all employees. 

This paper will compare and contrast these two universities in their approach to 
technology and user support and the policies and procedures they use for end user 
training. The similarities and differences between fi*^ training and fee-based 
courses — similarities based on the nature (rf hi^-qi ality training programs and 
differences brought about by the structure of the institutions — may help other 
institutions plan for training programs of their own. 

Both authors are managers of training programs for central computing organization 
at their respective institutions. 
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Introduction 

A group of college and univcrsit> technology educators in southern New England began meeting 
regularly in 1988 to discuss issues and share ideas about training at their respecrivs institutions. 
The eariy meetings, supported by Apple CcMnputer, focused on Nfacintosh training. Preliminary 
discussions revealed need to obtain a training profile of each of die rune institutions. The 
institutions include Boston College, Brandeis University, Brown University, Harvard University, 
MIT, Trinity College, Tufts University, Wesleyan College, and the U.S. Coast Guard Academy. 
The survey, completed by training manag^ or coordinators, gathered data about the training 
programs, classrocmi facilities, training policies and procedures, evaluaticm methods and muketing 
strategies. The sccticm identifying successes and challenges raised the issue of how policies and 
proce^'jres for training were established — tlrough central . 'date or by default — and what 
made particular training models work in each institution. 

Description of the Institutions 

Harvard University. Harvard University is decentralized: it consists of 1 1 graduate and 
professional schools and an undergraduate Faculty. Central administration consists of the 
President's and Vice Presidents' Offices, BudMt Office, General Counsel, News and Public 
Affairs, Alumni Association, Development Omce, Office for Information Technology, and more. 
Founded in 1636, Harvard is the oldest university in the United States. It awards at least 17,400 
undergraduate and graduate degrees each year. Supporting the studmtpq)ulation, there are 2400 
full-time and 600 part-time faculty members as well as a staff of 15,000. 

The University' of Michigan . The Univcisity of Michigan is also decentralized witii 16 graduate 
and professicmal schools and an undergraduate Faculty. The University commuruty in Ann Arbor 
is comprised of over 36,000 students* 3,000 faculty, and 15,000 staff. The University 
organization is comprised of the Offices of Bitsiness and Finance, Government Relations, 
Academic Affiairs, Research, Development, and Student Services. The Information Technology 
Division is headed tyy a Vice-Provost v;ho reports to the Vice-Prrsident for Academic Affairs. In 
addition to the main campus in Ann Arbor, The University of Michigan also includes a campus in 
Flint and one in Deaibom, with a Chancellor at the head of each. 

Recognizing the importance of Information Technology to the research, instructional, and 
administrative activity on campus as well as to the quality of life, the University has made a major 
cramiitment toward support of Information Technology on campus. The Information Technology 
Division consists of approximately 700 employees engaged in die provision of computing, 
communicaticx), and network services. A campus-wide network environment has been created the t 
c(Mmects the entire campus in a network of interlinked, local- and wide-area networks connecting 
mainfirame, microccmiputer, and minicomputer users . The network uses a variety of media 
including fiher and twisted pair wire. There art current^* 9300 asynchronous ports connecting 
faculty uid staff offices and student workstations in public clusters and residence halls. 

Plaiming and Budgeting 

HarvanL Planning u i budgeting occurs in each School and Faculty at Harvard before the central 
budget is crnipiled As wiA all other aspects of University life, the way budgets are done also 
affects information technology planning and implementatim. Individual Facdties and 
administrative Departments have developed systems to meet internal needs arul provided users with 
tools for data management. Concurrent with the increasing use of distributed computing is a plan 
to connect the entire canq;>us by fib^, enabling a computing network of pes, minicomputers and 
mainframes within Rve years. 
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According to the 1987 Long-Range Plan of the Office for Information Technology (OIT), "no 
University-wide framework for technology use exists at Harvard, and tiiere arc no University-wide 
standards and controls for implementation." The plan's objectives were, "in addition to identifying 
Orrs long-range goals and strategies, to begin a process for gaining consensus on these goals and 
to build awareness throughout Harvard of the University's future information technology needs." 

The plan emphasized tfiat information sharing tools are needed and diat extensive training is equally 
miportant in order to upgrade individual technology skills. OITs publications and its ccxnputer 
ttaining program were established in tiieir present form along witii this plan. The information 
dissermnation and training services are designed to raise consciousness about information 
technology in higher education, and are intended to stimulate discussion and increase customer 
self-sufficiency in using information technology. 

Altiiough there is no central noandatc about technology at Harvard, expenditures in tiiis area grow 
at the rate of 8 percent per year. With no central standards. OIT can only set some de facto 
standards through sales of a limited range of hardware and software at die Technology Product 
Center and by providing training for selected software packages. Individual schools set their own 
standards and provide tiieir own computer support structure, which may or may not offer training. 

Michigan- Budgets at Michigan are also prepared by each individual school, college, or 
adnrinistrative unit Since 1984. die Information Technology Division budget has grown from 4 
milUon dollars to its current level of 17 million. The majority of tiiis funding is comprised of direct 
funding from the University's general fund, but it also includes revenue from tnninftuny charges 
to external clients and modest user fees. Having recently realized many of its important strategic 
goals (mcludmg die installati<m of a campus-wide network and die deployment of 1600+ 
woricstations in campus computing sites), it is expected that the ITD budget wm remain relatively 
stable in die near future. Increases to die budget arc more likely to corr« as a result of additional 
user fees dian from additional central funding. 

Qnnputer support in a decentralized university sudi as The University of Michigan is not 
surprisingly also decentralized. While at one time it was tiiought tiiat a "centralized, controlled, 
rational approach to a microccnnputer environment at die University of Michigan would be nearly 
impossible to achieve^" computer support is now best characterized as die result of individual 
units woridng togedwr for mutual benefit While it is tme tfiat diere is not a "centralized and 
controlled" environment, tiiere is a great deal of "rati(Mial diought " being expressed. Individual 
units can make whatever decisions tiiey wish for die acquisition and support of information 
technology, but it is not unusual to find decisions being made in favw of ITD-supported solutions. 
We find tiiat support responsibilities are tjpically shared ~ witii general support usually provided 
by die central service and discipline-specific support provided by individual units, schools, and 
colleges. 

Several mechanisms exist for sharing information and shaping suppOTt policies. Of key 
importance is die concept of ITD supported products. Individual units know what products are 
supported and what services diey can rely on from die Informatim Technology Division. 
Evaluation teams made up of botii ITD and non-ITD personnel mate recommendations for 
supported products. An ITD Selectim Committee makes final support decisions based on die 
availability of support resources and die perceived demand fw a particular product Information 
about needs and directions for information technology are shared at regular meetings of several 
can^us groups of computing support professionals and key policy makers from widiin and 
beyond ITD. 



*The Univcisity of Michigan UCCPU Subcommittee Rqwrt "University Microcomputer Policy" January 4th, 
1984 
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G(Hiq>uter Education aid Training 

Harv-anL OIT*s training classes aie open to the entire University as well as to non-profit 
institutions in the area. These classes are hands-on, skill-building sessions offered in two 
dedicated classrooms in Cambridge and one shared facility in the medical area in Boston. During 
the 1988-89 acadenndc year, ntiore than 90) people were trained on the Macintosh and the IBM 
PC/PS2 in 121 classes of 21 different courses. People taking these classes were representative of 
eligible organizaticxis: 60 percent were staff members from all Harvard schools, 19.5 percent were 
from Orr, 2.7 percent were faculty, 3.8 percent were graduate students, .8 pcrcttit were 
undergraduates, and 13.2 percent wm horn non-profit institutions. 

In addition to classes, the technology education group of three professional people, under the 
management of Aime Knight, organizes a colloquium series, hosts user groups, and holds product 
denx)nstradons throu^out die year. The educational program has grown steadily since 1986. 

Most of OITs services are supported by user fees. Very litde central funding is provided The 
classroom must be full cost recovery. Thus, the importance of high quality programs and services 
is obvious. The biggest challenge is to determine client demand boax the widely scattered audience 
and to set fees appropriate to the market Harvard's training program must be as good if not better 
than its conq)edtors and must be offered at a lower price. The setting of goals and standards for 
OFTs training program became vital to its success. 

Michigan. Ccmiputer education programs at Michigan are designed for faculty, staff, and students 
of the University. Non-University participants are eligible only for the University's mainframe 
(MTS) classes. Michigan's end-user computer education program began with mainfirame training 
in the 1970's. In 1984, with the influx of microcomputers and Michigan's participation in the 
Apple University Qmsortium program, workshops became an effective and efficient way to 
communicate with the rapidly growing numbers of novice computer users who needed to learn 
more about what computers could do for them and who needed to develop their coiiq)uter use 
skills. Since 1984, the workshop program has grown enormously. Current education programs 
include: 

• regularly-scheduled workshops 

• self-guided instructional materials (print and computer-based) 

• training the trainer activities 

• special workshops 

Regularly-scheduied woikshops are offered in systems use (Macintosh, DOS, and Michigan 
Tenxdnal System), application areas including electnmic messaging and conferencing, database 
management, spreadsheeting, word processing, data conununication, local area networks, 
authoring systems for creating multi-media courseware, and workshc^s to facilitate access to UM 
data. There are over 14,(XX) registrations for workshops each year and over 1 ,800 hours of 
instruction in more tiian 100 different wcnkshop titles each semester. 

Workshops are offered in a variety of formats including lecturo/demcmstraticMis and hands-on 
classes. A Macintosh classroom and an IBM PS/2 classroom are regularly used fw hands«(Hi 
classes, ^ach of tiiese rooms contains 16 workstations and overiiead projection capabilities* The 
computers in the IBM Lab are OHinected to one anodier on a local area network with a networic file 
server ccmtaining all programs and practice exercise files. The Macintosh lab will be added to the 
same networic as soon as c(»nmercial releare connected to one another on a local area network with 
a network file server containing all programs and practice exercise files. The Macintosh lab will be 
added to the same network as soon as possible. A 3rd classroom equipped with a Macintosh and a 
PS/2 used for lectuitft/demonstration workshops. This room is also equipped with projection 
equipment for each computer. 

Pages 



273 



The workshop population at Michigan is con5)oscd of approximately 55% staff, 39% students, 5% 
faculty, andl% MTS clients. This is not an exact minw of tfie University statistics for these 
groups. Faculty arc representative, but staff clearly outnumber students in workshops. 

The University of Michigan's Computing Center education program is managed by Elaine 
Cousins, assisted by a staff of 5 full-time instructor/consultants, a full-time registration clerk, and a 
part-time secretary. Staflffix)motherareasof User Services also regularly teach workshops. Their 
time commitment may vary from 6 hours <rf classroom instruction per term to over 40 hours. In 
addition to the Computing Center education program, other ITD education programs include the 
Office of Administrative Systems program (with 3 teaching staff) and tiie Residence Halls program 
which makes use of student trainers to teach students in the residence halls. 

Because workshops are not the only way to teach about computers, self-guided print tutorials and 
computer-based tutorials have been created These include introductory training on mainframe use 
and the widely-used computer conferencing facility at Michigan. A scries of tutorials on basic 
concepts of computer applications is currently in progress. 

In keeping with the desire to help users help themselves, the University of Michigan Ccmputing 
Center assists departmental trainers, faculty, and teaching assistants to teach computer topics using 
Computing-Center developed materials. Approximately 20 groups took advantage of this service 
last year and it is anticipated that more will do so in the coming year. 

The end-user education budget at Michigan is approximately 300,000. This represents salaries, 
material preparation and production, advertising, and software for teaching. Not included are 
teaching lab hardware costs , staf f expenses for supplies and equipment, and non-education group 
salaries (approximately L5.FTE). 

IV. Goals and Standards for Training at Each Institution 

Harvani! The goals ofHarvard's training program are to: 

• impart skills to its customers 

• maintain high-quality course content and delivery 

• have satisfied, repeat customers 

• build and maintain a good reputation for OIT 

The classroom standards that were established include: 

• an instmctional methodology with lecture, demonstration, and hands-on exercises and 
group problem-solving in the advanced courses 

• in-class opportunity to practice 

• one person to each machine to provide a hands-on experience 

• a comfortable learning environment — a bright, clean classroom and an assistaiit for large 
classes; 

• using current, appropriate, reliable technology 

• regular support by a technical person. 

Michigan. The goals of The University of Michigan's computer education program are to 
contribute to the quality of instruction, research, and the administrative woik environment by 
facilitating better use of Information Technology. We do this by: 

• Providing information about Information Technology resources on campus 

• Enhancing the con[q)uting skills of the U-M and MTS community 

• Assisting faculty and computer support staff with their cducatioiVtraining responsibilities 

• Encouraging self-help and strategies for continued learning 
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The pzogram standards we have adopted to help us realize these goals include: 

• talented and knowledgeable instructors who are an integral member of our support team 

• up-tOHdate training equipment in confoortable classrooms with overhead projection equipment 

• varied formats that encourage active learning and problem-solving 

• supportive, group-oriented environment widi 2 students per workstation in workshops 

V. Policies and Procedures 

Harvard The mission of the training program at Harvard is to increase the customers* skill level 
and self-sufficiency in using information technology. The overriding management objective is to 
make die classroom function full cost recovery, ifigh standards were established to attract clients. 
Timeliness and clarity is important for marketing the courses. A training catalog published each 
semester is distributed in September and January as an insert in the Technology Window 
publication to all 1,400 Harvard employees. Certain courses, such as SAS, require targeted 
mailings, and publicity in the medical area has received special attention. General publicity is 
handled through calendars in odiei Harvard publications and via announcements on Harvard's 
information telephone number called FACTLINE. We miaintain a training information telephone 
mailbox and "hotUne" to respond to customer questions. Decisions about each semester's 
offerings are based on software sold at the Technology Product Center, software used by OIT staff 
and discussed in the User Groups, and on information gleaned from other information technology 
fomms at Harvard 

Introductory courses for die PC and the Macintosh are offered more finequendy than intermediate 
and advanced courses, and they are offered in two half-day segments. The intermediate and 
advanced courses are one and two days long (7 hours each, including mid-moming and mid- 
aftemoon breaks and an hour for lunch), depending on the amount of material to be covered. In 
addition to die operating system courses, word processing, desktop publishing, spreadsheets, 
databases, and statistics courses are offered. File transfer and local area network training is also 
offered. Adjustments to die schedule are made each semester, based on past experience. When 
use of software packages represents a critical mass, training programs are offered, and support is 
provided 

Pre-registrati(Hi for all courses is required via mail or in person, with payment and confirmation 
letters sent acknowledging enrollment. Fees range firom $12S/day for introductory courses to $395 
for three- day courses. Stu^nt rates are $15 to $70 lower, depending on course length. When a 
class is filled die registrant is contacted about enrolling in die next class offered Waiting lists are 
maintained if necessary. Cancellation within five working days is accepted with full refund* GIT 
reserves the right to cancel classes with insufficient enrollment (\tss than fiv^. people) or because of 
inclement weather. Failure to show up for a class does not entitle the student to a refund. 

The student/teacher ratio is 8 or 9 people. If there are more students in IBM PC classes, up to a 
maximum of 12, a classroom assistant is hired. No assistant is provided in the Macintosh 
classroom where 9 students is the maximunt 

Aldiough prerequisite skills are defined for all classes, frequendy students come to classes they are 
not prepared to take. This year we have instituted a self-assessment skill test, which is sent to all 
registrants with their confinnation letters. This enables students to determine whether or not their 
skiUs are sufficient to proceed to a highor level coiirse. 

The problem of varying levels of expertise among die student population is handled by die 
instructors. They adjust dieir rate of instruction to die majority of die students and try to provide 
extra help for slower students during the exercises. 
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Technical support is provided for all classrooms. OITs technical support person prepares the 
systems before class and is available to tioubleshoot any problems Aat may arise during class with 
the network, the individual systems, the projection nnit, or the printers. 

Harvard contracts with independent trainers as instructors. Each instructor is selected on the basis 
of an interview and recommendations from other employers. They are evaluated during their first 
course by the manager. Their fees are negotiated and depend on level of experience, amount of 
course development necessary, and on years taught for OIT. 

Fortunately we have never had to cancel a class because of instructor illness or failure to show up. 
V^'e do not have baclcup provisions for instructors, so "the show must go on." 

Course outlines are prepared by all instructors, and either third-party courseware or instructor 
developed courseware is used for instruction. Bibliographies and "cheat sheets" are prepared by 
the instructors. OIT provides each instructor with a policy manual and technical notes. Twice a 
year the instructors meet with the OIT staff to review, discuss, and evaluate the past semester. 
Often, suggestions are adopted by all the instructors. 

At the end of all classes, the students complete a course evaluation form. These evaluations are 
reviewed by the instructor and the training coordinator. Problem areas are discussed immediately 
with the instructor, and appropriate adjustments are made to course content, length, or 
presentation. 

A Paradox database is maintained of all registrants on a PS/2 Model 70. This database is updated 
regularly with data from the central Human Resources database. Reports can be generated upon 
request on enroUment (numbers, distribution according to department or staff type), courses 
(name, type, number, hours, fee, etc.), and income and expenses. Ihese reports are used for 
planning puiposes and preparing the Department's annual report. 

Some Departments or offices at Harvard request special training sessions, especially if they have 
more tfian five people to be trained. These sessions are scheduled according to classrrom and 
instructor availabiUty. OccasionaUy on-site training is provided, especially for the President's and 
Vice-President's offices. When OIT cannot meet a training request, we refer people to outside 
vendors or try to acc(Mnmodate the request next semester. 

As yet, OIT has not developed follow-up surveys of our customers. In order to reach the faculty, 
a needs analysis may be conducted in the spring of 1990 to determine their desire and availability 
for twining sessions. 

Michigan- Policies at Michigan have grown out of our experience and our desire to offer high- 
quahty, effective programs that meet the needs of our participants. 

Dependability and Consistency: 

Because it is important for the campus community to be able to plan ahead, an entire semester's 
schedule is published one month in advarice of the coming semester. Information about the 
workshop schedule is available in a Computing Center publication, Non-Credit Confuting 
Courses on Campus , as well as in other campus publications published each term by the Human 
Resource Development office and the Hospital TYaining Department Our ITD newsletters and 
general Urn versity publications publish weekly workshop schedules as well. An o.dine file that is 
widely accessible on campus also carries information about workshops and any last-minute 
schedule changes. 
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In order to narrow the gdp between participant expectations '^jid reality, our publications try to 
clearly convey exacdy what will be covered in a workshq) and what prerequisite skills are 
necessary* Infoniiation is also provided about the length and format of the workshop. 

So that it is not necessary to cancel workshops in the event of an instructor illness, substitute 
instruaors are available and specially-prepared "Instructor Notes** are assembled in notebooks for 
;eference. Workshops are cancelled only in the case of insufficient enrollments (fewer than S 
registrations for advanced, limited-audience classes and fewer than 10 for traditionally more 
popular classes). 

Printed materials have become an important part of Michigan*s workshop in'ogram. Some are 
designed as reference materials while others are step-by-step tutorials. In either case, our 
participants have come to expect high-quality support materials for post-workshop use. Many 
people also find that our handouts substitute for attending a workshop when their schedules are 
particularly busy. 

Excellent workshop instructors are particularly inqxntant to our program's success. Our 
instructors are very knowledgeable and enthusiastic teachers who enjoy traiiung. Instructors woric 
in teams to design new workshops and are available as consultants to users both before and after 
workshops. The wcokshops they design grow out of their experience on the U-M campus and 
reflect campus needs. Wherever possible, we try to assign more than one person to teach a 
particular woiicshop tide. This helps when we need substitute instructors and it also makes 
consistency in workshops essential. Instructors of advanced courses need to know that the same 
material is covered in introductory courses regardless of which instructor may have taught it. 

Appropriate Scheduling: 

Schedules are planned taking into account University class schedules and the curriculum is 
nxxlularized so that individuals can sign up to leam the skills they need. Although we have very 
few evening woikshops, we have scheduled some to accommodate students, faculty or staff who 
find evening woikshops nxMe convenient Registration and enrollment statistics are monitored 
carefully so that we can offer the right number of workshops each term and at die right time of the 
semester. In general, introductory courses are offered more often than advanced classes. 

Qassroom Policies: 

A myriad of policies and procedures seem to govern attendance and registration. All ot our 
policies, however, are designed to improve the classroom experience of those attending or 
eliminate a *'no show** problem. 

Some of our classroom policies are: 

• Late-comers forfeit their seats to **walk-ins** 

• Registration is required, but walk-ins are encouraged 

• Registrations are accepted no earlier than one month in advance 

• Class limit of 30 participants for hands-on classes 

• 2 participants per workstation is die norm 

• No eating or drinking in the classrooms 

• No mail registrations to enable immediate confirmation of registration 

• Modest fees are charged for all but introductory workshops and hands-on systems use 

workshq)s. (typically $5.00 per hour, no charge for students) 

Other Policies: 

Computing Center developed tutorials are distributed for a nominal fee ($10.00) and may be 
duplicated freely. Commercial tutorials will be available for checkout beginning in the winter term. 
Print tutorials and woricshop handouts available for $2.00 or at no charge (for workshops that have 
no fee.) 
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SpecuJ workshops may be requested by faculty or departments. Departments are charged roughly 
$150/hr for special workshops and development time for special workshops that are not regularly 
taught IS charged at 40.00 per hour. An estimate is givcjn to each department requesting special 
workshops in advance. 

Program Analysis and Ongoing Improvement: 

At Michigan, we monitor our program and its effectiveness regularly. Workshop evaluations are 
completed by participants after each session and these are compiled for each workshop each 
semester. Instructors are the first to receive the evaluation data and often respond to feedback in 
the evaluations mimediately. Participant e 'al-iations are also very useful for identifying problem 
areas that can be addressed m a special meeting. Some recent such topics have included enhancing 
presentation skills, teaching to a mixed level participant group, handling questions, and teaching 
newly amved foreign students. Longer-term follow up evaluations have not been carried out with 
the exception of special workshops where the Education Manager always talks with the organizer 
of the traming several weeks after the training has been completed. 

Consultants provide input into the curriculum planning and registration and attendance data are 
analyzed for trends and indicated changes to workshop schedules. Beginning next term, we will 
be mstituting a plan for peer evaluations. The Education group meets biweekly to address any 
problems that anse and orce or twice each semester, the entire teaching staff assemble for topics of 
mutual interest and the sharing of teaching tips and skills. 

I. Challenges for Training Programs at Each Institution 

Harvard- The ongoing challenges for Harvard's training program are: 

• requiring full cost recovery for the classroom, which includes all overhead expenses (space 
rerital, instructors, staff support, course materials, printing, telephone, hardware and 
software, etc.) 

• setting and maintaining standards for course materials (course descriptions and outlines, 
prc-tests, student materials in proper sequence with page numbers, quick reference sheets, 
integrated exercises, bibliography, and student data disks) 

• keeping our excellent instructors happy ^ay com»-nensurate with skill and experience, 
providing staff assistance, dinner meetings semiannuallv) 

• getting students to self-assess their skills and enroll in appropriate classes only. 

The challenges for the future of Harvard's training program include: 

• preparing and training faculty to evalnate and use tecl? oology for personal and professiaial 
tasks by cooperating with computer services groups within the various Schools 

• keeping up with the rapidly changing technology (when to upgrade and what expenditures 
for hardware and software to capitalize) 

• developing effective training coordination mechanisms within Harvard (regular meetings of 
user support managers ftom the various Schools, quarterly meetings of training 
coordinators and trainers, etc.). 

Michigan- Challenges for Michigan in the coming year are numerous and revolve around budget, 
changuig technologies, and changing user needs. Among the more interesting are: 

• Reaching increasing numbers of users with static resources 

• Keeping up with rapidly changing technology and changing user needs 

• Narrowing the gap between experienced and novice learners in the same class 

• Continued exploration of alternative training media and strategies 

• Becoming an effective lobbying voice for user needs and improved software 

• Helping users work "smarter" with new technology 
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ABSTKACT 

The ever-increasing computer usage at Allegheny College demanded an 
increase in computer support. By 1987 the 450 employees and 1900 students of 
Allegheny used eighteen different word processors. 

The Computer Center found that standardizing on one word processor was 
one way to increase productivity without increasing computing staff size. The 
complex change process required the support of top management as well as user 
involvemrat in the decision. Workshop training with hands-on experience was 
found to be the best strategy when teaching novice users. A users' group allowed 
for continuing user involvement. Project evaluation using a questionnaire 
provided necessary feedback. 
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A METHODOLOGY FOR STANDARDIZATION: 
FROM EIGHTEEN WORD PROCESSORS TO ONE 

This paper reviews the procedure used at All^hoiy College to standardize the use of 
won! processing. Founded in 1815, Allegheny is a small, private liberal arts college. The 254- 
acie campus located in northwestern Pennsylvania in Meadville is 90 miles north of Pittsburgh. 
Meadville is a small city of 15,000 people, surrounded by fiarm country and rolliiig wooded hills. 

The methodology for standardization included the following steps that proved successful: 

1. Needs assessment 

2. Top nuuiagement support 

3. User involvement in the decision process 

4. Questions and answers 

5. Workshops and training 

6. Distribution of the software 

7. Formation of a Users' group 

8. Project evaluation 

The Need to Standardize 

Before standardization, the 450 employees of Allegheny College used eighteen different 
word processors, many at different version levels. The most popular were PC-Write, Multimate, 
Volkswriter, WordPerfect, WordStar, and MS Word. The 1900 students primarily used PC 
Write. Support and training for all these packages was a very time consuming no-win situation 
for the Computer Center staff. 

The quality of support offered by a compute- center depends upon three factors: the staff, 
the number of products supported, and the level of support offered.' If the majority of the 
college community were to use one versatile, powerful, user-friendly word processing package, 
we would be able to concentrate our support on one good package. 

By January 1938, it was sppmnt to the Computer Center staff that an attempt must be 
made to standardize on one word processing package at Allegheny. In addition to improving user 
support, standardization makes tlie exchange of information much easier and increases efficiency. 
The Computer Center performed an evaluation of major word procesang packages to select the 
most appropriate program as a standard for All^eny. Product reviews and professional 
literature suggested that WordPerfect was the most widely used and highly rated word processor 
on the market.' A recent survey of CUMREC members also found WordPerfect to be "the 
easiest and most helpful software."* The package met our criteria of bemg both easy to use and 
learn, with powerful and versatile features for both general and academic use. The Computer 
Center suggested that Allegheny College adopt WordPerfect as its standard. 
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Adminfatritlvfi VxtcsMv^ CommUti^ fi..pp,>r» 

Research indicates strongly that in any complex change process, there is a critical group 
of people whose commitment is necessary to provide the en&gy for a change to occur/ Support 
of top administration is essential when attonpting to effect most organizational changes. All 
dq)artnient heads had to be willing to supply the time required for training. 

The first step in this process was to approach All^heny's Administrative Executive 
Committee (AEC), comprised of senior officials rqwrting directly to the president. The 
coopoation, support, and guidance of this committee was sought from the outset of the 
standardization effort. 

By the end of February 1988, the AEC agreed in principle to support the concept of 
limiting support to one or two standard word processon on campus. They requested the 
development of a formal mechanism for selecting the ai^ropriate word processor. They believed 
it was important for the users to play an active role in arriving at the decision. They shared a 
common belief that resistance can limit die success^ implementation of computer applications ' 
Us^ involvement tends to reduce resistance, "ilie users needed to have a strong input. 

The AEC wanted a vehicle for all constitue;icies of the collie - student, faculty, and staff 
- to provide input to the final proposal. As this retraining effort was to affect all membors of the 
collie community, the AEC saw it a an opportunity to improve communication on campus. 
If workshop participants could discuss the type of work each did, people would to get to know 
each other better. As participants discovered that they shared many similar concerns and 
problems, an increased sense of community might develop. Forming a users' group would 
provide an opportunity for people to come together on a r^ular basis. Thus a secondary goal 
of standardization was to provide opportunity for communication across boundaries. 

The AEC gave its support for funding aa two conditions: first, that workshops would 
include a mix of people from different offices and different levels of authority; and second, that 
a users' group would be formed. 

Word ft-ocessing SfamdardlMtion Committer 

The Computer Center b^an to discuss ways to involve the entire collie community in 
the decision. We rejected the idea of sending out a questionnaire and explored the idea of an ad 
hoc conrnittee. By May 1988, we had focused on the formation and purpose of the Word 
Processing Standardization Committee. This committee was to make explicit the reasons for 
adopting a standard word premising package at AUtgJct • Using the existing evaluation 
materials provided by the Computer Cento*, we wanted th jm> 'ttee to take into considera^on 
cost, power, flexibility, and ease of use and learning. We andcipated this committee would reach 
the same conclusim we reached, choosing the same word processing package that we had in 
mind. The decision had to be made as soon as possible so training could take place during the 
summer months when the computer labs were available for employee use. 
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In June 1988, the committee was formed. The Word Processing Standardization 
Committee included five staff, three administraton, three foculty, and three students. We chose 
members not only from various ar^as, but also with various computer backgrounds. The 
chairperson of the committee was a member of the Computer Center staff. The Computer Center 
prepared a working document to simplify the task fiEu;dng this committee, emphasizing that it was 
only a recommendaticm. The committee would analyze the material within this document, and 
discuss the issues and strat^es with colleagues. As iq)resraiatives of the college community, 
they would build a consensus around a final strat^y for standardization. The docummt included 
the following reasons and objectives for standardization: 

1. Commiuiicatioii Communication cannot hBppen when everyone is speaking a different 
language. Standardization provides the ability to exchange information effortlessly with any 
office, administrative or academic. A free flow of information eliminates both communication 
l>arriers and problems of misinformation and q)eculation. 

2. Community Better communication makes for better working relationships and increases 
understanding among groups. Standardization would require cooperation among the many offices 
on campus who have similar needs but rarely find occasion to discover the similarities. The 
entire campus working as a ^eam toward a single goal could bring the college community 
together. 

3. Integration To have everyone using the same tools encourages a sense of creativity, 
harmony, and organizational solidarity. 

4. Efficieney When multiple word processing packages are used, employees must use a 
conversion program or retype to share documents among offices. Secretaries in academic 
departments find then^selves working with documents ftom faculty who use different word 
processors. All of these tasks waste time and energy at a time when emphasis on improving 
productivity continues to increase t All^haiy. 

5. User Satisfaction and Productivity Research shows that two important factors that impact 
end user compc^g are the efficient and productive use of available software and the quality of 
interaction with computer specialists.* The level of training, and support the Computer Center 
could provide by concentrating on one package should improve botti factors. This would lead 
to increased productivity, expertise, and user satisfaction. 

6. Quality One of our goals was to equip faculty, students, and staff with the best possible toe's. 
We evaluated several word processing packages and found what we judged to be the most likely 
software to meet the needs of almost all groups on campus. The package we recommended has 
powerful, easy-to-use features for general and academic word processing needs. 
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Questions far the CnmpMter Tenter 

The prospect of standardizing raised several questons, issues, and problems that needed 
to be addressed: 

1. Tnm^on We expected a poiod of transition during which the new standard word processor 
and the old word processors would all be in use. The transition poiod would take approximately 
one school year for administrtive users. Converting £EKnilty and students would take longer 
because of the numbo- of upperclassmen using PC-Write and the time constraints faculty face in 
attending training workshops. During the transitim we would cratinue to support the most 
widely used word processors. Any new employees and students would learn the standaid 
package. 

2. Time We saw the commitma;t of time to be the most universal problem. This commitment 
must have priority and come from the top down. Department heads must give staff the time to 
leam the new package. We anticipated each person learning the package would spend tai hours 
in workshop training over a period of 2-3 months. The time to achieve competency in the new 
software would vary omsid^ably fiom person to perscHi. For optimal results, we suggested that 
people begin using the new program immediately after training. For about one month, we 
estimated this could add one hour per day to the time it would take them to accomplish their 
normal work. We also recommended that for about one month trainees spend 1-2 hours per week 
away from their offices to work on the program, preferably in the microcomputer labs where 
people who knew the package would be available to answer questions and provide help. 

3. Training Individualized instruction is most eff'<:tive whoi teaching won! processing. A small 
group accommodates differences in learner abilities, attitudes, and backgrounds.^ We planned 
to conduct workshops aticnded by no more than 18 participants with two instructors for each 
group. 

We planned to provide training in steps - an introductory session, an intermediate session, 
and then workshops on advanced topics. This would give users the opportunity to work with the 
program, absorb what they learned, and formulate questions before the next session. Individuals 
did not need to attend the introductory session if they felt comfortable with basic features of the 
program. They could attend the intermediate or advanced levels as they saw fit. The sessions 
emphasized the type of work participants were most likely to do with their word processor in 
their own working oivironment. 

4. Support We had in mind a number of support mechanisms. The formation of a uscts' group 
would provide excellent and timely help for people having problems and an opportunity to share 
helpful hints discovered while using the package. Each office would identify a word processing 
ocpert. These liaisons would answer most questions and act as the word processing contact with 
the Computer Center. Telephone support from the Computer Center would also be available. 
We would distribute tip sheets and handouts. 
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5. Access/DistribuUoD The standard package would be available o? all college-owned computers 
and networks. Anyone who had his or her own equipmoit could purchase the software for a 
highly discounted rate. WordPerfect is not a public domain program. Unlike PC-Write, we 
could not duplicate and distribute it free of charge. 

Word PfOCMSl ng Stiin*"***^"^"" rftmmlrt*^ IWkiftn 

The Word Processing Standardization Committee met twice. During the first meeting the 
members discussed the problems and concerns. The committee made the decision to support 
standardizatimi on Wonfferfect during its second meeting. If this project were to be a success, 
it was important that the uso^ understand the reascms for standardization, the commitment to it, 
and the long-tun benefits.' To meet this requiiemoit, on July 18, 1988, the committee sent a 
memo to the Allegheny community. Many areas in tfiis memo reflected the recommendations 
of the Computer Center to the Committee. This memo presoited the rationale for standardizaiion 
and the reasons for choosing WordPerfect as a standard. 

Workshops and Training 

By mid July 1988, the Compute Crater had n^otiated a license agreement with the 
WordPerfect Corporation and ordered the software. It was time to formalize the training process. 
Many trainera say problems arise when users with diffnent levels of PC experience and different 
job requirements are together in the same workshop.* However, one of our aims was to improve 
communication across the campus by getting people together. We chose to include employees 
from various departments in each workshop. In order to stimulate conversations, each worktop 
included a IS minute coffee and cookie break. Users are mo/e likdy to seek help after thdr 
initial training if they are pers(Mially acquainted with the support staff." The coffee breaks 
allowfd the Computer Center to become acquainted with the users in a personal, friei:dly setting. 

Now the problem we faced was who would teach the workshops. Up until this time, 
two people from Academic Computing taught nearly all computing workshops. Both had 
octensive experience teaching workshops, and one was the WordPerfect exp^ on campus. 
However, these two computer professionals could not possibly teadi all workshops. Although 
the test of the Compute Center staff had no knowledge of WordPerfect, everyone would join 
in and help with the training. 

Here is where the plan met some resistance. "Any programmer, any DP type, any 
computer scioitist, wants to program, not train."" Some of the staff were very reluctant to teach 
workshops since they had neither teaching experience nor training. One person refused to teach 
a workshop; the rest said they would, but they were hesitant because of their lack of «cperience 
with WordPerfect. A key ingredient in workshops is the instructor. The instructor must have 
a deep understanding of the program. It is important that he or she understands the feats and 
{prehensions of new users. In additicm to prior teaching experience, instructors should have 
extoisive ocperience with both the personal computer and the software that they are teaching." 
Many of us were mainframe programmer/analysts who had never used WordPerfect. Most of 
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US had no teacher training. So what were the chances for a successfii' training program? The 
workshops had to be a success. We could not risk failing in even one workshop group. 

Our solution was to have the inexperienced teachers assist the experienced trainers in the 
early workshops to get a feel for what to expect. This worked out quite well. Even the one 
programmer/analyst who had refused to teach a workshop agreed to give it a try. After assisting 
in several workshops, we ficlt comfortable enough to teach, and in feet, we enjoyed it and did 
a good job. 

Along with the July 18, 1988 committee memo, we sent a memo to all administrative 
offices announcing the WordPerfect workshops. We asked each office to identify the employee 
who would serve as the word processing liaison for the department. Liaisons were considered 
the key word processing experts in each office and would be the fint to receive training in the 
paclrage. They acted as the contacts with the Computer Center, received the software for 
distribution, and converted files from other word processors wh«i necessary. When users had 
problems, liaisons would be the first people to consult. 

Focusing on Allegheny's 125 administrative users, we conducted ten Introductory 
workshops and five Intermediate workshops during July and August. Each workshop met for two 
two-hour sessions. The Introductory workshops required no experience with WordPerfect. 
These workshops covered basic features of the package. The Intermediate workshops were for 
those who had taken the Introductory workshop or had a working knowledge of WordPerfect. 
They covered such features as working with blocks of text, advanced printing features, and 
search/replace. 

Advanced workshops met for one two-hour session. Conversion workshop #1 showed 
how to use the conversion utility provided in WordPerfiect. Conversion workshop #2 showed 
how to use Mastersoft's Word for Word to convert files created in Microsoft Word or 
Volkswriter. The Mail Meige workshop covered the techniques of merging a list of names and 
addresses with form letters. A Documoit Processing workshop dealt with the use of WordPerfect 
with the HP Laserjet. 

The mix of staff, administrators, and faculty in the workshops was roughly 4:2: 1 . Each 
workshop had participants from an average of eight different offices. The workshops were 
definitely accomplishing the goal of bringing together the different groups on campus. People 
were mingling and introducing themselves to others, mostly because of the coffise and cookie 
breaks we included. We gave people time to talk and get to know each other. Everyone we 
talked to, including those of us teaching, enjoyed the workshops. 

Distribution 

On July 25, 1988, we distributed one copy of the WordPerfect software (six disks) to each 
compute on campus, accompanied by a quick reference card and a keyboard template. Each 
copy included instructions for using WordPerfect from floppy diskettes, installing and using 
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WordPerfect from a hard disk, and selecting a printer. Manuals were distributed at a ratio of one 
manual for every three machines. 

Users could check out world)Ooks with stif-paced lesscms from Academic Computing 
Savices. We DID NOT recommrad using the on-line tutorial tiiat comes with the WordPerfect 
prograip as we v;ere experiencing some problems with it. This worted to our advantage since 
research shows that an on-line training package is a less efifecUve teaching method than workshop 
training." 

WordPterfect Usgrs^ Group 

End-user attitudes toward word pnx^essors affect efficiency and productivity. Assuming 
that more positive attitudes produce greater job satisfaction and productivity, we attempted to 
improve user attitudes.'^ In August 1988, we formed the WordPerfect Users' Group as the 
medium for exchanging solutions to problems, macros, and other helpful information. We 
oicouraged anyone interested to attend the meetings. Two college employees with PC 
experience, who were not membc;s of the Computer Center staff, coordinated the users' group. 
This was a fiuth^ attempt to involve the users. The Users* Group planned to hold informal 
monthly meetings in a computer classroom where dem<Mi<:uati(»is could be givra. 

Problems 

Many of the problems we experienced with the project were anticipated and measures 
were in place to deal with them. Other problems were un^pected. One major problem we 
encountered was that as we were about to standardize m WordPerfect 4.2, WordPerfect 
Corporation came out with a major upgrade-WordPerfect 5.0. "There are substantial differences 
betwem the two versions."'^ Not only did we have the task of teaching WordPerfect to the 
college community and ourselves, there was no one on campus who was an expert at 
WordPerfect S.O. In addition, WordPerfect 5.0 requires 384K memory while version 4.2 
required only 2Q5K. Nfany of our PCs had only 256K memory. Version 5.0 runs best on a hard 
drive or a network with lots of free spsice.^^ 

Another p-^oblem was that during this same time frame, many offices were converting to 
laser printers and hard disks. Besides learning a new software pack^e, users were dealing with 
new hardware. Often calls concerning WordP^ect were actually questions having to do with 
the new hardware. 

We logged all calls and reports of problems, sending students or personnel out to help 
usen when necessary. Most problems seemed to be with printers. An IBM Wheclprinter drivw 
was not available at the time we received the WordPerfect software. Eighteen ofnces on campus 
used the Wheelprinter. Furthermore, we had to experiment with suitable drivers for older dot 
matrix printers not supported by WordPerfect 5.0. As problems arose, we prepared handouts 
outlining solutims or ways to avoid the problems. These handouts as well as several useful 
macros were distributed through the users' group. 
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Prolggt Evahiatlon 

Although the standardization process was for from being complete, in November 1988 we 
performed an evaluation using a questionnaire sent to all employees of the coUege. This feedback 
would allow us to make modifications to the plan if necessary. Of the 450 employees receiving 
the questionnaire, 36% respmded. 

The questionnaires were analyzed using SPSS-X. Of those responding, 30% were 
administrators, 36% were faculty, and 34% were staff. Of the 59% using WordPerfect 5.0, 
33% were adn^strators, nearly 27% were fiaculty, and 40% were staff. Of those responding 
to the survey, 61% attended a workshop: 87 attended the Introduction, 63 attended the 
Intermediate, 19 attended the Mail Merge, 9 attended the Document Processing, and 12 attended 
the Conversion workshops. The workshops were rated exceUent by 61% of the respondents, 
good by 34%, and fair by 4%. None of the employees rated the workshops poor. 

De^ite the positive ratings, comments on the questi(Mmaires pointed to three areas in need 
of improvement. First, the constructive criticism illustrated the importance of workshop 
evaluations. Before the tixt round of workshops in December, we would design an evaluation 
firnn to b5 completed by participants at the conclusion of each workshop. This immediate 
feedback would allow us to monitor the quality of instruction and make timely adjustments. 

A secono difficalty involved our practice of integrating users with various levels of 
compi:ter expntise into a single workshop. Tc meet our goal of providing cross boundary 
communication, we combined users with different levels of PC experience. We overlooked the 
option to include users from various areas without including users of various levels of PC 
ocpertise. To eliminate this problem in future workshops, we would eithw match participants 
by ability, or require users with litfle PC experience to attend the Introduction to the PC 
workshop. Employee comments also led us to question the timing of the workshops. 
Participants in the summer WordPerfect workshops often attended an Intermediate or Advanced 
workshop without enough practice at the introductory l<jvel. ^forcing prerequisites would 
alleviate this problem. 

ciQsiiig nwHights 

Throughout this project we have stressed user involvemoit. Research shows that the 
training strategy not only affects learning efficiency, but also affects attitudes end users develop 
toward the system." We expect the favorable ratings of the workshops to carry over into the 
work area. 

The first wave of training, with over 300 participants, was a success. We will omtinue 
to offer WordPerfect workshops, asking participants to perftnm an evaluation at the conclusion 
of each workshop. We have learned that fbedback is a necessary part of the change process. 
Thus far, feedback shows that our expectations are being met. 



8 



33 



Endnotes 

1. Tumolo, P., and Saltzbeig, S. (1987). How do you support a campus-wide office automation 
system and end user services? Proceeding 8 of the 1987 CAUSE National Conference. Tarpon 
Springs, Florida. 

2. Menddson, E. (February 29, 1988). WordPerfect. PC Magazine , pp.322-326. 

3. Hebblethwaite, J. (198S). PC's - promised land or paradise lost? CUMREC 1988 . Los 
Angeles, California. 

4. Beckhard, R., and Harris, R. T. (1977). Organizational transitions: managing complex 
change (p. 53). Reading, Ma: Addison-Wesley Publishing Company. 

5. Amdt S., Feltes J., and Hanak, J. (1983). Secretarial attitudes toward word processors as a 
function of fomiliarity and locus of control. Behavior and Information lachnology. 2, 17-22. 

6. Danziger, J. N., and Kraemer, K. L. (1986). People and Computers . New York: Columbia 
University Press. 

7. Czaja, S. J., Hammond, K., Blascovich, J. J., and Swede, H., (1986). Learning to use a 
word-processing system as a function of training strategy. Behavior and Information Technology. 
5, 203-216. 

8. Lechner,H.D. (1984). The Computer Chronicles . Belmont, CA: Wadsworth Publishing Co. 

9. O'Leary, M. (August 25, 1987). A juggling act: training a spectrum of users. PC Week. 
pp.54-60. 

10. Karon, P. (March 1987). Coping with reluctant users: managers need strategies to keep 
users computing. PC Week , pp. 41-56. 

11. Krasnoff, B. (August 25, 1987). Information centers: coping in the midst of change. ££ 
3Kfifil£, pp.54-63. 

12. Olson, D. O. (1985). Getting the most from personal computers. In Umbaugh, R. E. (Ed.), 
The Handbook of MIS Management (pp. 295-302). Pennsauken, NJ:Auerbach Publishers Inc. 

13. Czaja, S. J., Hammond K., Blascovich, J. J., and Swede, H., 203-216. 

14. Amdt, S., Feltes, J., and Hanak, J., 17-22. 

15. Alfieri, V., (1988). The Best Book of WordPerfect Version 5.0 . Indianapolis, Indiana: 
Hayden Books. 

16. (April 1988). Preparing your computers. In Wilkes, A. B. (Ed.), The WoidPerfectionist 
(pp. 3-6). Baltimore, MD: Support Group, Inc. 

17. Czaja, S. J., Hammond K., Blascovich, J. J., and Swede, H., 203-216. 



9 



34 



DATA ADMINISTRATION: 
Problems and Solutions 



289 



Ronald G. Hoover 
The Pennsylvania State University 
University Park 
Pennsylvania 



ABSTRACT 

This paper describes some of the problems encountered in the 
administration of data at The Pennsylvania State University and the 
solutions that have been implemented to solve these problems. It 
is recognized that the technical aspects of these solutions may not 
be applicable everywhere, however, the techniques presented will 
hopefully stimulate ideas for solutions to similar problems at 
other institutions. 
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INTRODUCTION 



The implementation of data administration can vary widely from one university 
to another. However, some of the problems encountered in administering data 
are conanon to organizations that have active data administration functions. 
It is the purpose of this presentation to describe the structure of data 
administration at The Pennsylvania State University, and to detail some of the 
solutions to problems we have encountered. 

Hopefully this discussion will provide useful information to those who are 
contemplating data administration, and alternate solutions to problems 
experienced by organizations that have already established data administration 
functions. 

DATA ADMINISTRATION HISTORY AT PENN STATE 

Data administration has existed at Penn State for many years. Initially it 
was in the form of policies, procedures and security measures that were 
necessary for the normal day day operation of the computer department. As 
systems grew larger and more numerous, a more formal method of keeping track 
of university data was needed. This need was met through the acquisition of a 
system called Pride from M» Bryce & Associates Inc. Pride used oaper forms to 
collect and relate information about files, records and data elements. The 
system was good for the collection of information but proved inadequate for 
reporting purposes. To correct this situation, a in-house system was 
developed to place the data from the forms onto magnetic tape. Updating and 
reporting facilities were also developed. This became the first machine 
readable dictionary used at Penn State. The administration of this system was 
the responsibility of the systems development group. 

In 1974 the University acquired IMS as its first database management system. 
At that time a database administration group was created and ass^imed many of 
the responsibilities associated with data administration. In 1982 work began 
on a major effort to develop new student systems using the ADABAS database 
management software and its fourth generation programming language NATURAL. 
The new systems are on-line oriented and have created an environment where 
more data is available to more users than ever before. This environment 
emphasized the need for a more formal data administration function which was 
established in 1986. The goals of this function are as follows: 

1. Institutional data are to be: 



d. 



a. 



c. 



b. 



Accurate 
Complete 
Accessible 
Secure 



-1- 




291 



2. Information systems are to be: 

a. Coordinated 

b. Consistent 

c. Efficient 

d. Protected 

e. Flexible 

f. Accommodating 

DATA ADMINISTRATION ORGANIZATION AT PENN STATE 

With the establishment of the above goa^s came one of the first problms 
encountered by most organizations contemplating data administration. Where in 
the organization's structure should data administration reside? At Penn State 
it was decided that data administration '^ould not be empowered in a single 
person or organization; rather, all units interacting with the system would 
share the responsibilities of data administration. Identified below are the 
key participants and their responsibilities: 

1. Executive Director of Computer ana Information Systems 

The primary responsibility of the Executive Director is for 
initiatives for system planning, policy development and research 
activities that affect data administration. The initiatives are 
undertaken with the direct involvement of the Committee for 
Administrative Systems Planning in which key offices are 
represented . 

2. Manager of Data Administration 

The Manager of Data Administration ie responsible for facilitating 
and coordinating overall data system planning, policy development, 
research activities, communication, system efficiency, data security 
and data accessing. The installation, maintenance and efficiency of 
the database and data dictionary systems are also the responsibility 
of the Manager of Data Administration. 

3. Data Stewards 

Each data element in the administrative systems is assigned a 
steward. The stewards are responsible for developing coding 
structures for data, ensuring data accuracy, determining updating 
frequency, establishing requirements for data protection and 
authorizing access to data within the stewards area. 

A. Access and Security Representatives (ASRs) 

ASRs are established in the major offices of the university and are 
responsible for requesting access to data for their organization and 
for ensuring appropriate access, use and protection of the data 
within their purview. 

-2- 
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Executive Director 
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Information Systems 



Director 
Management Services 
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Assistant Director 
Information Resource 
Management 



Manager 
Data Administration 



Figure 1 
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Of the above participants, the Manger of Data Administration is the most 
active. This office handles the typical data administration functions of the 
University. The placement of this function is usually critical to the success 
of an organizations data adoinistration efforts. Figure 1 shows Penn State's 
placement of this function within the central administrative data processing 
department which reports to the Executive Director of Computer and Information 
Systems and the Provost. This structure has advantages in permitting datn 
administration to work directly with the operations, process control and 
security staffs to enforce standards and take immediate action in controlling 
data access. In addition, the database and data management staffs report 
directly to the Manager of Data Administration and provide technical expertise 
for software and systems solutions to many problems. 

A Potential disadvantage of pliacing the data administration function in the 
data processing center could arise when a problem occurs that affects 
organizations over which the Manager of Data Administration has no Puthority. 
Generally these problems take .longer to resolve but have been successfully 
addressed through the coordination of data administration and th'.^ data 
stewards. In the event a problem cannot be resolved, the data administration 
reporting structure permits the escalation of the problem to the Executive 
Director of Computer and Information Systems and potentially to the Provost. 

USER ACCESS TO DATA 

The first challenge that faced data administration at Penn State was to 
provide a way of requesting access to computerized institutional data that 
would meet the needs of the users and all parties involved in the 
authorization process. From the users standpoint, a vehicle was needed that 
would allow them to identify the particular data they wanted to access. The 
data stewards wanted information describing why the data was needed and how it 
would be used. They also desired the capability of specifying any 
restrictions that were to be imposed on the use of the data. The security 
office required an identification of the individuals who would access the data 
and a signed statement that the users understood their responsibilities for 
using data as outlined in university policies and as agreed to by the 
stewards. Data administration needed a way of recording the request and 
subsequent approvals or disapprovals of everyone involved. In addition, it 
was highly desirable that the process be kept as simple as possible. 

The initial solution to this problt m was the design of a general form for 
requesting access to computerized Institutional data. It was decided that a 
single one page form would reduce confusion on the part of the requester and 
aid in the standardization of the request process. The front of the form, as 
illustrated in Figure 2, is completed by the access and security 
representative from the requesting affice. This portion of the form is used 
to identify the data needed, the reasons for the need, and the individuals who 
will access the data. Each individual is uniquely identified by a "userid" 
assigned by the security office. The back of the form, as shown in figure 3. 
is used to record the signatures of those involved in the request, approval 
and implementation processes. In the event additional space is required, 
additional pages are attached to the form. When a request is completed, a 
copy of the form is returned to the requestor and the original form is filed 
in the data administration area. 
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pennState 



Manaftmcrl ScrvicM 



Request to Data Administration 

for Access to 
Computerized Institutional Data 



3 Shteldi Ruilding 

Tht Penniylvtnia Sutc Univcrtily 

Univcraily Park. PA 1U02 



MGMT SVC USB ONLY 

Log Number 

Date Rec'd - 
DateStewd - 
Date Ret'd - 
Access Est - - 



1 . PURPOSE of REQUEST: 
(Specify why d»t» is needed) 



2. SCOPE of DATA REQUIRED: 

(Specify desired populetion, seleaion critene, »nd speci fi< de u vilues - if epproprie te) 



3. msrmmoMAL data required: 

(Ust specific file nemes, or list of dete elements. Attsch edditionsl peges - if necessary) 



4. time PERIOD: 

The data is requested for the period from ^to or 

Semester , | | Quarter , | | Current. 

OTHER 



5. INDIVIDUAL ACCESS INFORMATION: 

(inttr ustrlOs of individutis from your tn* who will icceu tht datt) 



Figure 2 
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6. ACCESS and SECURITY REPRESENTATIVE SIGNATURE. 

I affirm the data I acceot will be used in accordance with the agreement specified by the 
Steward(s) of this data and I have read and understand University Policies AD-20 "Data 
Security and Pnvacy' and AD-23 'Use of Computerized Instituticnal Data' 

tt^SSS.' Administrative Area : 

(Please print) 

Signature . Date: 



Forward the completed form to the Manager of Oata Administration 
3 Shields R'lilding, University Park. 



7. DATA ADMINISTRATION ACTION: 

Request Approvyi Disapproved 

Commenti : 



Signature: Date : 

(Manager of Data Administration) 



8. DATA STEWARIXS) APPROVAL: 

I agree to release the requested data which is under my stewardship, under the c • >ditions 
and time periods noted on the reverse side of this form. 



Steward's office Signature 



Date 



Restriaions (Attach additional sh^t. if necessary) " 
Steward s office "Skl^-tU^ " OatT 



Resuictions (Attachaddltionaisheet if necessary) 



MANAGEMENT SERVICES APPROVAL: 

Signature : ^ Date : 

birector. Management Services 



10. INFORM-alON CENTER ACTION: 

The following data sets were created to '^tisfy this request. 



Signature : 



Date: 



11. INSTALLATION SECURITY OFFICE ACTION: 

Appropriate access was established for this request. 
Signature Date: 




Figure 3 
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The above process has worked well over the past three years with only minor 
changes to the request form as dictated by experience. The next step in the 
process will be to include the request form in an electronic approval system 
that will eliminate the paper form and speed up the approval process. This 
system will also provide requestors the capability of monitoring the progress 
of their requests. 

ELEMENT CLASSIFICATION SYSTEM 

The request form was not in use very long when another problem presented 
itself. Requests began to appear asking for access to entire data base files 
rather than individual fields. In these cases the stewards were provided with 
listings of their data elements from the requested files. For some stewards 
this meant reviewing listings of up to a thousand data elements. At times the 
steward would just finish one review when a request from another user would 
start the process all over again. Needless to say, the stewards soon asked 
for a better way to handle access requescs. 

What appeared to be needed was a system that would allow the stewards to grant 
access to classes of data elements rather than individual dat^ elements. This 
meant the stewards required a methodology to group their dat«« elements for 
access authorization purpose . The first proposal for providing thij 
methodology used government classifications such as top secret, secret and 
confidential. Th' proposal was not well received for two reasons: The 
stewards felt tha. terms such as top secret and secret did not fit into the 
university envirDnment, and no one could decide on a set of criteria for 
classifying data into these categories. A second proposal was then made that 
was more structured in its approach. It called for only two categories: 
classified and unclassified. A work sheet was also provided to aid in the 
classification process. The work sheet listed six factors to be considered 
for each data element. These factors were: 



1. 


Competitive value 


2. 


Fraud potential 


3. 


Legal liability 


U. 


News-worthiness 


5. 


Financial exposure 


6. 


Impact on management decisions 



This proposal was also rejected. The stewards felt that two classifications 
levels were not enough and the factors on the work sheet were difficult to 
apply across the board. The third time is a charm and the third proposal w&u 
accepted by the stewards. It involved classification levels of 0 through 3 
and two simple rules. Rule 1: Data elementii classified at level 0 are 
available for anyone to access. Rule 2: Classification levels are inclusive 
of the levt s represented by lower level numbers. For example, a user who is 
give access to level 2 data will also have access to level 1 and 0 data* 
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other than level 0, attempt was made to define the meaning of levels 1 
through 3. The stewards were free to create their own criteria for assigning 
elements to each level. The classification levels are maintained in the data 
dictionary for each data element. Now, when a user requests access to a file, 
the stewards simply specify access to a classification level. As is sometimes 
the case, the solution of one problem often highlights another problem. The 
stewards were now able to authorize access in record time but the creation of 
tailored user views to match those authorizations was a painfully slow manual 
process. This was made worse by the fact that a given file usually contains 
elements for many stewards and therefore many access levels had to be 
considered in the creation of a user view for the file. 

AUTCTlhlED USER VIEW SYSTEM 

Eliminating the manual process for creating tailored user views was the next 
challekige to be addressed. The data dictionary system provided an on-line 
capability for creating user views from file descriptions. However, it was 
not able to use the steward's element classifications in the process. Half of 
the solution to this problem was in place with the documentation of data 
element classifications in the dictionary. What was needed was a system to 
link the element classifications with levels of user access authorizations for 
each steward and each file, and then to automatically create tailored user 
views based on these links. An existing code table file was used to contain 
the link information. A new code set was defined that contains an entry for 
each unique file, user and steward combination. The entry also contains the 
level of data access approved by the steward for the user. The final piece of 
the solution was the creation of an on-1.' a program to read the code set and 
dictionary and create a user view that is tailored to the approved access for 
a particular user. 

As with any system, exceptions do arise. Occasionally a user will request 
access to elements at a level higher than they have been authorized. When 
this occurs the stewards have four choices: 

1. Authorize the user for the higher level. 

2. Change the classification level of the elements in question. 

3. Disapprove the request. 

A. Grant access to the elements on an exception basis. 

Choices 1 through 3 are handled by the automated user view system in normal 
fashion. Choice A requires some additional processing. In these cases, the 
code entry containing tne user's access authorization is flagged to indicate 
an exception exists. The user view generation program then accesses another 
code set that identifies the data elements to be added as exceptions. The 
stewards have done a good job classifying their elements and the use of the 
exception process has been rare. 
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During the design of the automated user view systero, provisions were made to 
select an alternate element classification xevel for sensitive data elements 
when used in conjunction with entity identifying elements. For example* a 
data element containing grade information may have a classification level of 1 
if used alone or with other elements that do not identify a particular entity. 
This permits studies to be done on grades with no links to entities such as 
students or colleges. However, if the grade data element was requested along 
with entity identifying elements such as stuaent id or college name, the 
access level of the grade element can be raised to 2 or 3. The stewards have 
the ability to designate entity identification elements and to <?pecify 
alternate access levels for any data element. It is interesting to note that 
this feature has not been utilized. The stewards have opted to maintain a 
simplt^r system based on a single element classification. 

DATA DICTIONARY USER ENHANCEMENTS 

As institutional researchers and other users began accessing university data, 
they uncovered problems in the documentation of data elements in the 
dictionary. Typically, the element descriptions in the dictionary were 
created by individuals who worked closely with the data and had an in depth 
knowledge of it. As is often the case, these individuals assuned a similar 
understanding on the part of others and their documentation was difficult for 
the uninitiatr»d user to understand. This problem was further compounded by 
tlie fact that the dictionary did not provide good facilities for the storage 
and retrieval of the kind of textual information required by the user. 

The first step in the solution of this problem was for the users to get 
together and develop a list of the kinds of information they felt should be 
part of the data element documentation. The list they created is as follows: 

1. USAGE INFORMATION - This cacegory of information describes how an 
element is used and interpreted. Some examples are: 

a. Descriptions of a}«orithms used to calnulate element values. 

b. Unexpecte'i fu.atures of the format of an element. 

c. Cautions about the use of elements that have known limitations. 

d. Time aapendencies and order of entry for arr^y elements, 
a. Any special requirements for interpreting the values of an 

element . 

2. VALUE INFORMATION - This information describes: 

a. Legitimate values for an eloni nt. 

b. Default values 

J. Indications of what values mean as well as what they do not 
mean. 

d. The effective dates for specific values. 

3. UPDATE INFORMATION - The data to be collected in this category is to 
reflect: 
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a. How an element is updated. 

b. When it is updated. 

c. Who is responsible for the update. 

4. RELATIONSHIP DATE - The information in this category describes 
relationships to other data elements and processes. 

5. HISTORY INFORMATION - This documentation lists the date a change was 
made to an element and describes how the element was affected by the 
change . 

A form was designed for the collection of the above information. A separate 
form for each data element was printed and distributed to the appropriate 
stewards for use in providing the requested data. A policy was also 
established requiring the completion of the form for new data elements and for 
changes to existing elements. This policy is enforced by the data 
administration staff which is the focal point for data element maintenance. 

The second part of che solution v^s to design a data base to contain the new 
information and to develop an on-line system to access and maintain the data. 
The scope of Lhe on-line system was expanded to include access to the regular 
data dictionary as well as a keyword data base. The keyword database is 
created by selecting words from data element names and descriptions and 
sorting these words to form a cross reference to the data elements. Whe.i used 
through the on-line system, this cross reference permits the user to select a 
keyword of interest, such as "degree", and view all data elements that contain 
this subject in their element name or description. A generic keyword can also 
be entered to allow access to all elements with keywords beginning with the 
selected characters. All on-line users have read access to this system and 
stewards have read and update access. Whenever an update is made by the 
stewards, the system enforces the creation of a history record to document the 
reason for the change and the date it was made. Future enhancements to the 
system will provide the stewards with an on-line capability to view the 
accesses they have approved through the previously described element 
classif icatio.i system. They will be able to view approvals by user or by 
file. 

The solutions presented in this oaper to the problems encountered at Penn 
State have taken advantage of the vendor software in use for database and data 
administration. While the technical aspects of these solutions may not be 
totally applicable to similar problems at other institutions, the ideas and 
techniques presented should be adaptable to most environments. 
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Most academic institutions' long-range plans call for 
the implementation of automated aids to system 
development, including a full complement of CASE 
tools. In order to fully utilize the benefits of 
these tools, a computing organization must have a 
well-defined structured development methodology and 
must follow it religiously. 

The University of Akron, like many other institutions, 
has been using a well-ingrained classical methodology 
for many years. This presentation discusses the 
development and implementation of the University's 
Structured ^^oject Life Cycle. It covers the 
investigation of the various structured techniques to 
be adopted for analysis, design, development, 
maintenance, and project management; the development 
of procedures for building the data models, process 
diagrams, and structure charts, and the training 
methods used to ensure Implementation of che new 
methodology. Future plans for modification of the 
project life cycle to accommodate future tools are 
discussed and several recommendations are made. 
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INTRODUCTION 

"By the 1990s, CASE tools and software development 
workstations will be as coinxnon to software development 
as programming languages and compilers have been for 
the last three decades. Computer-aAded software 
engineering will take a central position among 
software technologies." - CARMA MCCLURE 

As recently as a year ago, I was one of those who felt they 
had heard all of this before and that the whole idea of CASE 
and structured systems development was going to be just 
another "flash-in-the-pan" • A couple of very important things 
have happened to change my mind. 

The f j.rst was rhe realization thac our traditional techniques 
were no longer having the desired results. Although systems 
were being developed at a fairly decent rate, the designs were 
not standard, even among the project leaders that had been in 
the department for many years. Additionally, files and 
databases were being designed and built that were totally 
unacceptable. Access to these files, even when they were very 
acceptable to the user, were difficult to maintain and ignored 
institutional data needs that should have been considered. 

The second thing that happened was the "legitimization" of 
CASE and structured techniques. I*m referring to the 
announcement of AD/CYCLE by IBM and the adding of three of the 
top CASE product companies (Bachman, Index Technology, and 
KnowledgeWare) to the IBM "partnerships". 

Although I*m referring to this as a "case study", it is 
actually an unfinished case study. We have gone only part of 
the way toward implementing the structured technic[ues and the 
CASE tools. In my contacts with other universities and 
corporations, I have found that most of us are at approximately 
the same point. We have either made the commitment to utilxze 
structured techniques or have decided to stick with the 
traditional techniques until the dust settles. 

This is the story of how we made our decisions and hov we plan 
to go about implementing the tools. 



ENVIRONMENT 

The main campus of the University of Akron has a student 
enrollment of just under 29,000, making it the third largest 
of Ohio's state universities. The academic and administrative 
computing on campus share the facilities and resources of the 
University's Computing Centor. 

2 
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The University of Akron's administrative systems utilize an IBM 
3090/200 running MVS/XA. Most of our programs were written 
in-house using COBOL and CICS. We use Easytr.eve plus for 
batch report generation for both users and programming staff, 
IMAGINE for batch query for our users, SAS-Graph for our batch 
graphic needs, and over the last two months, have developed our 
first set of online screens using IBM's Cross System Product 
(CSP) . 

The Model 204 relational database from Computer Corporation of 
America (CCA) was installed late in 1986 and several systems 
have been constructed utilizing Model 204 's utilities. 
Including a complete rewrite of the Accounting System. During 
the last few months, a commitment has been made to install 
IBM's DB2 as a second database. 

Over the last twenty years, administrative applications have 
been Implerented in all of the major areas: student systems, 
financial systems, human resource systems, alumni/development 
systems, and physical facility systems. There are currently 
64 different systems that Include a total of 3,200 programs. 
The number of programs in a system range from a bookstore 
report system consisting of one program to the personnel 
system with 374 programs. We spend about sixty percent of our 
productive time maintaining and modifying these systems. 



REOUIREMENTS FOR CHANGE 

In the spring of 1986, the University completed a five-year 
plan for computing. The seven committees that de>^eloped the 
campus plan over a period of about six months covered the major 
automation topics of: large mainframes, micros and minis, 
graphics, office automation, computer based education, 
administrative systems and programming, and networking and 
telecommunications. 

A great deal of the good planning of these committees has 
already resulted in the implementation of some fine automated 
systems, what was missing was any commitment toward the 
development of new systems development techniques or the need 
for them. Th-a closest anyone got toward suggesting such a step 
was the recommendation that 

"—a primary effort be exerted by the Computer 
Center's Administrative Systems and Progrcunmlng 
department on providing the support necessary to 
enable the University's administrators to better 
utilize the available data and that these needs be 
given major emphasis." 

The actual requirement for making some changes came from 
several other sources. 
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First, we had been trying to update our development life cycle 
for several years. The current development techniques have been 
in use since 1974, are totally traditional, and are based on 
manual operations to be automated and the subsequent delivery of 
specific documentation. 

Second, there have been many requests for Executive 
Information Systems (EIS) and Decision Support Systems (DSS) 
from the highest levels of the University. These requests may 
not be a direct request for EIS or DSS, but will show up as a 
request for a quickly-needed inquiry covering averal years of 
comparative data, some type of forecast, or a v,raphics output. 
Although we have set up a "Quick Response" group within the 
department, this is not the long-term answer. 

Third, with the commitment to DB2, it has been emphasized that 
a good solid set of development techniques based on structured 
methods was a necessity if we were to be successful. 

Fourth, it became apparent during the analysis and design of 
;:he last couple of database systems that our systems developers 
r:ould not rely on traditional design methods and develop an 
acceptable system. 



LIFE CYCLE METHODOLOGIES 

Over the years, the primary objectives of the project life 
cycle have remain unchanged. According to Ed Yourdon, they 
are: 

1. To define the activities to be carried out in 
a systems development project. 

2. To introduce consistency among many systems 
development projects in the same organization. 

3. To provide checkpoints for management control 
for go/no-go decisions. 

Whether you were using a version of the classical project life 
cycle or of the waterfall model of systems development or a 
combination of both, the objectives stated above still 
remained valid. The problem stems from the fact that all of 
these methodologies required a sequential progression and 
bottom-up implementation. 

According to Ed Yourdon again, the difficulties with requiring 
a sequential progression are as follows: 

1. It doesn't allow tor raal-world phenomena such as 
politics or project .'eaders who make mistakes. 



2. It allows for user indecision; indeed it is very 
coininon for users to change their minds several 
times during the development of a system. 

3. It relies on outdated techniques; in fact, it 
totally ignores structured techniques. 

There are several other difficulties listed by Ed Yourdon when 
bottom-up implementation is demanded: 

1. Nothing is done until it's all done; there is 
nothing to show the user during development 
other than an enormous pile of listings. 

2. Trivial bugs are found at the beginning of 
testing, serious bugs are found at the end. 

3. Debugging is extremely difficult during final 
stages of system testing. 

4. Requirements for computer test tim«» rise 
(exponentially during final stages of testing. 



STRUCTURED METHODQLQGTFS 

For several years now, there has been a growing recognition 
that structured techniques were available to help us solve our 
problems. The big question was: how do we go about implementing 
ther? Some organizations went to a semistructured project life 
cycle. Although it utilized top-down implementation and the 
coding and testing of high-level modules first, it was still a 
largely manual effort the depended on narrative specifications. 

Another version of the top-down approach that has become 
popular lately is the prototyping life cycle. Although I do 
consider prototyping to be a useful part of good development 
life cycle, I don't see this type of life cycle as a complete 
answer to the development problem. 

The structured project life cycle as proposed by Ed Yourdon 
contains nine activities: survey, analysis, design, 
implementation, acceptance ttst generation, quality assurance, 
procedure description, database conversion, and installation. 
There is a lot to say for the planning, analysis, and design 
procedures i^j this life cycle, but the process is hard to learn 
and the various documents to be delivered by each of the 
activities are difficult to produce without heavy manual effort. 

Unlike tiie traditional approach, any or all of the activities 
can be taking place simultaneously, in fact, the "radical" 
approach calls for all activities to take place in parallel. 
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STRUCTURED TOOLS - CASE 



There are now more than a hundred companies selling 'CASE" 
tools. Even 4GLs are now being called CASE tools if they 
generate some type of code. 

My definition of a CASE tool is a tool that automates the 
structured techniques. By this I mean a series of programs 
that automates the development of the various components of 
each of the structured activities, maintains the information 
in a master dictionary, justifies the various relationships 
between the components, and generates the code. Any changes 
to the system should require changes to the components, not to 
the code. 

Carma McClure lists 40 software packages as representative 
CASE full life cycle tools. T*m not sure I agree with her. 
Most of the tools listed depend on another tool for completion 
of the full life cycle, lor example. Index Technology's 
Excelerator has excellent planning, analysis, and design tools 
but, at the current t,^?ne, depends on another product such as 
Telon or Micro Focus to generate code. 

We have only found two tools that we feel are full life cycle 
tools - KnowledgeWare*s Information Engineering Workbench 
(lEW) and Texas Instrument's Information Engineering Facility 
(lEF) . More about them later. 



SYSTEMS DEVELOPMENT AT THE UNIVERSITY OF AKRON 

The project development life cycle in use at the University of 
Akron since 1975 contains fovr activities: systems survey, 
systems design, systems definition, and programming. The 
deliverables are in narrative form except for a couple of 
manually produced flow charts. In fact, nowhere in the 
Computer Center's standards manual is this called a "life 
cycle". It is merely a list of items to be delivered after the 
system is developed. 

As I mentioned earlier, we ^lave been trying to develop a new 
developr-*-nt methodology for many years. Our latest attempt 
(about year ago) had five activities: project initiation, 
requirements definition, system design, programming and testing, 
and Ituplsmentation. Although data flow diagrams, prototyping, 
and structured walkthroughs were listed as parts of the 
activities, the basic idea was still a sequential, bottom-up, 
traditional life cycle. Because of disagreement among 
management as to the actual structure needed, it was never 
implemented. 
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The University of Akron made its first jump into the database 
arena in late 1986 with the purchase of Model 204. Prior to 
that time, lack of hardware resources made that move impossible. 
Several medium sized systems were developed and the rewrite of 
the Accounting System was our first major effort in Model 204, 

Although the development with Model 204 was successful, the 
i. ter facing with other systems was difficult. If we could have 
stopped all development and taken the time to rewrite all of our 
systems ir Model 204, it would have been very acceptable. 
However, ^his was never considered an alternative. 

As we added new application tools and longingly looked at 
others, it became evident that Model 204 was not in the 
"mainstream" and was most likely not going to be. Most tools, 
including CASE tools, had not been developed with Model 204 in 
mind. 

The commitment to inclement IBM's DB2 was made about six months 
ago. 



CASE PROGRESS 

The whole area of CASE tools and where they fit within the 
applications development picture has become much clearer within 
the last couple of years and the tools available have had a 
tremendous increase in capabilities. I have attended some good 
sessions at CAUSE over the last couple of years presented by 
happy users of Excelerator and lEF. 

We looked closely at Excelerator from Index Technology. The 
flexibility and usabi' ity of the system are apparent and th-y 
have a great track record. i»m sure there are several 
Excelerator user»s at this presentation today. The only 
shortcoming we saw was the need for a separate product for code 
generation. 

We also looked closely at lEW from KnowledgeWare. Like 
Index Technology, KnowledgeWare became an IBM partner a couple 
of months ago. Unlike Excelerator, lEW now haS its own code 
generator. 

The four activities in lEW (planning, analysis, design, and 
construction) and the components of each are well integrated. 
Since James Martin is the head of this company, it necessarily 
follows his Information Engineering m.ethodology very closely. 
Because of the automated integration of the various components, 
the flow of the resultant life cycle is also much easier to 
understand than the nine step approach proposed by Yourdon. 



Carma McClure lists the following benefits to be gained from the 
Implementation of a CASE supported methodology: 

1. Makes structured techniques practical 

2. Enforces software/Information engineering 

3. Improves software quality through automated checking 

4. Makes prototyping practical 

5. Simplifies program maintenance 

6. Speeds up the development process 

7. Frees the developer to focus on the creative part 
of software development 

8. Encourages evolutional and Incremental development 

9. Enables reuse of software components 

She lists the following causes of CASE failures: 

1. Confusion about what Individual CASE products actually do 

2. Using CASE tools to address problems for which they were 
not Intended 

3. Placing too much emphasis on CASE tools as a whole 
solution 

4. Ignoring the Importance of good management 

5. No development methodology or standards In place 

6. Poorly Integrated CASE tools 

1. Poor tool documentation and training 

8. Not enough functionality present In CASE tools 

9* Unclear about which software problem needs to be solved 

10. No methods for measuring Impact of CASE on software 
development and maintenance 

11. No software development methodology training 

12. Indecisive - unwilling to make a decision about how to 
use CASE technology 

13. Unwilling to change current way of developing and 
maintaining software 

14. View CASE as a high-risk technology 

15. No plan detailing how to Implement CASE technology 

What, then, Is the most frc -^ntly used development methodology 
In the United States? Nea 30% of the structured technique 
users use Yourdon's structured design. Gane-Sarson and DeMarco 
users together make up about 25% of the total with Orr and 
Jackson u'sers making up another 10%. 



THE STRUCTURED PROJECT LIFE CYCLE 

The development life cycle we will be Implementing has seven 
steps; project Initiation, requirements definition, system 
design, programming, system testing. Implementation and 
production, and post Implementation review. This Is fairly 
close to the Yourdon structure that I mentioned earlier. In 
addition, data flow diagrams, entity-relationship diagrams, and 
structure charts, the basic-three of structured techniques will 
be Interjected as part of the life cycle. 
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The structured project life cycle we envision consists of seven 
steps: project initiation, requirements definition (to include 
the activities of planning and analysis), design, construction, 
system testing, implementation, and post implementation review. 
We plan on incorporating the lEW activities and components into 
this life cycle. 



IMPLEMENTATION 

In addition to the standards currently being developed for the 
structured project life cycle, there are other standards we are 
working on that will be implemented during the next six to nine 
months. These include CSP, DB2, and the CASE tool usage. 

One of the most important components of the implementation is 
the training of the project leaders and programmer/analysts. 
We started the training in May using two hour sessions every 
two weeks and planned to complete the initial training in nine 
sessions. So far, we have had about eight sessions and have 
made it through the requirements definition activity. The 
introduction to systems development alone took three sessions. 

We will restart the training sessions again after the holidays. 
We plan to cover the structured techniques first though before 
continuing with the life cycle. 

Another big question to be answered was whether or not to 
implement the structured techniques and the structured 
development life cycle fully before implementing a CASE tool 
(install them sequentially) or to go with the structured 
techniques and the CASE tool at approximately the same time. 
We decided on the latter approach because we feel that the CASE 
tools structure should help provide some badly needed 
consistency in our analysis and design. 



RESULTS 

We have already taken several steps on our long range SAA plan. 
We installed a local area network connecting all of the 
administrative project leaders and managers. We implemented 
CSP, completed the pilot project, and will be training 
additional users within the next few weeks. In addition, in 
preparation for DB2, we installed several upgrades to our 
operating software. 

The next phase will begin about the first of January, 1990, and 
should be complete about September. This includes the 
implementation of DB2, lEW, and severe^ other application tools, 
as well as training our personnel. 
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Future phases include expansion of the encyclopedia to the 
mainframe and additional JEW workstations in 199**, and the 
implementation > ; TIF and AS in 1992. 



RECOMMENDATIONS 

Structured techniques and CASE is the future. The two are 
singular: structured techniques will never succeed without CASE 
and CASE is useless unless structured techniques are 
implemented. 

Nothing good is cheap. Providing a full tool capability for all 
of your developers will be expensive from both a software and 
hardware standpoint, but the techniques and too3s can both be 
ohased in rather easily. 

Prepare to spend large amounts of time and money on training. 
Therr is some excellent training being provided by consulting 
rganizations at the present time. 

Seli^ sell, and sell. Everyone I talked to, even the most 
excited users, stresiaecl the need to continue selling management 
on the fact that CASE tools and structured techniques are the 
i^ystems tools of the 90s. 
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STRATEGIES FOR DEUVERING ON-LINE 
APPUCATION SYSTEMS TO A LARGE CAMPUS 

Warren H. Curry 
Administrative Computing Services 
University of Horida 
Gainesville, Florida 

Peter Maren 
Division of Human Resources 
University of Florida 
Gainesville, Florida 



ABSTRACT 

. 7^*5 R^P^r presents a look at the approaches, problems and successes of 
delivenng Adnumstrative Management Systems v.hich affect both Central 
Processing Areas and Departmental processing of information. These systems 
affect policy, procedures and training reoniredto operate the administrative 
functions involved. 

As system implementors, our management of the application development 
projects must be sensitive to the user's perceptions which inevitably surround all 
development projects. Our experiences in on-line systems at ^.c University of 
Florida have guided us to develop strategies which have been successfully used on 
several development projects. 
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Introduction 

Building information systems solutions that work effectively for a business is 
a tough job for all those involved. Top management must find ways to ensure 
success and economy. Users must learn to use equipment and processes which often 
seem foreim to them. Middle managers must rethini: the procedures and structure 
of their office and staff. They must learn to manage, ti ain, and motivate a group of 

geople experiencing drastic changes in their daily routines. The Information 
ystems fjepartment must become knowledgeable in many areas of the business. 
Tiiey must also maintain a high level of skill in rapidly changing areas of technology. 
Tht above forces have been common knowledge to most Data Processing Managers 
for years. 

Within the workings and agendas of u large public universiW such as the 
University of Florida (UF), these forces are diversified and multiplied. Projects 
undertaken in this environment must be closely managed and guided from mception 
through completion if you intend to implement successful Information Systems (I.S.) 
projects. Furthermore, you must continue to manage the project throughout the 
system's operational life' time. Lack of coordination between top management, 
operational managers, system users and information systems personnel will provide 
for a difficuh (perhaps impossible path) for developing quality information systems 
that work and continue to work as me demands on the university change. 

To provide insight into the magni:ude and scope of these issues at the 
University of Florida, the following p:ofile should be considered. UF is a top 20 
school in size of student population. As a member of the American Association of 
Universities ( ^AU), UF is among the nation's leading research universities. As a 
Land Grant educational facility, UF is responsible for Florida's Institute of Food 
and Agricultural Sciences (TFAS) and the related extension centers throughout the 
entire state of Florida. Also part of the university is a large Medical Center with 
related professional schools. It performs extensive research and operates many 
patient clinics. 

UF has 20 colleges and schools. All programs are coordinated and offered 
on a single campus of more than 800 buildings spanning 2000 acres. Program 
offerings include: 

137 Academic Departments 

114 Majors in 52 undergraduate degrees 

123 Masters degree programs 

76 Doctoral programs 

100 Interdisciplinary Institutes and Centers 

Post Baccalaureate Studies are also offered in law, dentistry, mediane 

and veterinary medicine. 

All these statistics indicate UF is a large campus with a wide diversity in 
procedures, needs and management styles. A staff of over 13,000 faculty, 
administrators and university support personnel and 35,000 students must be 
coordinated through the never ending list of aOiiiinistrative procedures, regulations 
and mandated requirements placed upon a university with a budget of over 900 
million dollars. 
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Administrative System Directions 

The University of Florida has installed many successful applications . ^ring 
the last 5 to 6 years. Some of these are listed in Table 1. 



Table 1: Recent Systems Developed or Installed at UF 



Project 



Installed Description 



P/P/B 7/84 



SAMAS 7/86 



Central Leave 6/87 

Performance Apprai& al 9/85 

ACCESS 6/89 

FTE/Effort 5/89 

Student Cashiering 8/87 



8/88 



Automated cashier 
Balancing 
Salary Commitment Tracking 1/89 

Pur cha s ing 5/88 

Purchasing Departmental 2/90 

Employee History 11/89 

Traffic & Parking 3/90 



Comprehensive On-line 
Integrated Payroll/ 
Personnel/Buc? ^et 
Statewide Accounting 
System with state 
provided software. 
On-line Personnel reave 
Management 

Support Staff Performance 
Central Employment 
Faculty Staff FTE/Effort 
Tracking 

Cooperative On-line 

Cashiering System 

End of day Cashier 

Balancing System 

On-line Salary Projecting 

On-line Purchase Request 

Management 

On-line Purchasing 

Departmental Entry 

Personnel Historical 

Retrieval 

Management of Parking 
Decals and Traffic 
Tickets 



The systems have been installed with a relatively small staff by industry 
standards, and we have had a hi^ level of acceptance by our campus community. 
More importantly, our Information Systems Staff has gained credibility and is in 
demand tor a number of additional development projects. 
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Several common directions persist throughout all of these projects. 
These concepts are described below: 



Systems are bein^ provided ON-LINE via an IBM CICS Administrative 
Application Region to staff stationed primarily on our campus but with 
access from facilities in most of Florida's 67 counties. These systems provide 
management areas a mechanism for collecting accurate information and fo: 
reduang paper flow and usage. 

Policy and audit enforcement can be built into the system. Massive time 
consuming reviews can be accomplished much easier via adhoc or routine 
reports. 

Centralized control of functions and information formerly recorded and kept 
in manual files are now accessible. Administration is able to track and 
evaluate information housed in the databases. For example, prior to the 
Central Leave System, employee leave records were kept in mana^ files at 
the employee's department. Once a year, or based on sampling visits, audits 
were done to assist in policy enforcement. Leave liability was known or\y for 
the annual financial status and only then through a lengthy data collection 
activity. We are now able to record leave faster and more accurately than 
before. The department clerks need to work only with leave usage. The 
system dti^termines leave earned automatically and accurately. 

Technology within the systems is continually being upfrraded as new tools 
become available for our use. Our approach to technology encourages our 
technical staff and management to use technology to assist the smooth 
working of UF. The choice of the most current technology for a project is 
not always necessary. As managers, you should evaluate all the issues and 
factors regarding an application and select the appropriate technology. 
TTiere are places for Batch, On-line, Cooperative Processing Techniques and 
for VSAM, DB2, Sequential, a.id tape in all of our day to day operations. 
Generally, however, you want to choose the most current tools. 

St^ff training for the efficient use and management of the i^stems has been 
encouraged at all levels of UF^s organization. Training ano skills are to be 
enhanced at our user departments, management areas ard within 
information systems. This is a continuing and ongoing activity which should 
begin early in every project and never stop even after the system is fiiUy 
operational. Ongoing training is an important success factor for systems on 
our campus. Turnover and chances in responsibilities is a constant problem 
to overcome. We have over 1000 terminals accessing our business 
applications and the staff using the network must be comfortable using the 
applications. 
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UF Administration has identified several areas of concerns which we closely 
monitor during each project. These concerns are managed jointly during and after 
the project by the "owner" and Information Syste:ns Department. Although varied 
in nature, each of the items below plays a key role in the production of a successful 
proj-jct. 

1. Technology and Methodology 

2. Security Management 

3. Communication (of the human kind) 
*. Departmental Training 

5. Staffing 

6. Management of Expectations 

The strate^es implemented for our projects are sensitive to the six items 
above. Attention is provided to all of ♦hese throughout a UF project. 



How Projects Begin 

. The TONE" and "STYLE" of interactions between participants of a project 
IS often influenced by the initial formation or conception ot z project. The term 
"How Projects Begin" refers io the origination of the concept or need for a new or 
enhan' ed information system. An awareness of the project origin will allow the I.S. 
department to present the solutions to users involved in more effective formats. If 
the I.S. department can keep tbs best possible working relationships with the system 
owners and related departments, the projects success will be more easily secured. 

UF has identified three basic points of origin. Upper management promotes 
the project to be implemented. This scenario ensures the high level VP support 
needed for a project. The operational owners and end users may need to be 
convinced in some cases that the system will be worth all of the implementation 
effort. They will be required to participate and are an important success factor 
dunng the system startup. The line managemi*nt will often conceive of ideas which 
deserve attention by I.S. and upper management. They must sell there idea to the 
VP in charge of their area so it can be studied for development. This situation 
provides a devoted and ready to work owner to implement and operate the system. 
The third type of project orgm often encountered is the external mandate. \Ve have 
all grown to expect and react as necessary to these often short deadlined requests. 

Implementation of information systems follow a three level thinking process 
for the project manager. First, "AWARENESS" of the problems that might occur. 
Tne second stage is understanding why these problems happen, "DIAGNOS :S". 
The third stage involves the 'TREATMENT' of the specific problems you have 
diagnosed. 1 The issue of who or where a project is started can affect the factors 
commonly associated with implementation success. Refer to Table 2 to review the 
factors. 



IDickson and Wetherbe, The Management of Information 
Systems . McGraw-Hill. 1985. pp380-409 
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Table 2; Factors Associated With Implementation Problems 



Factor Description 


1. 


Ease of Use 


The intended users perception of the degree 
of difficulty to use the system must be 
weignea ay^insi tne perceivea Denenis lo 
the user. 


2. 


Previous Systems 
Experience 


A previous bad or good experience can 
carry over to a new system activity. 


3. 


Data Problems 


it tne data is not or leit not to oe 
accurate or complete, the users will 
lose confidence and tend not to use the 
system. 


4. 


Perceived Need 


The users must perceive a need for the 
system for it to be used successfully. 


5. 


Control over 
Change 


People do not resist change, rather 
they resist not having control over it. 


0. 


Mutual 

Understanding 


Technical Designers and Managers must 
communicate a workable solution. 
Often there is failure to communicate and 
understand each other. 


7. 


Expectancies 


The way users expect a ^stem to 
contribute to their performance and 
their belief that performance is related to 
rewards they receive are important to ' 3w 
these users employ a system. 


Q 
O. 


Power and Social 
Change 


i ne roies oi power ano poiuicai 
issues involved include: 
rivalries 

territorial threats 
fear of obsolescence 
resistance to outsiders 
cultural factors 
worries of job security 
information possessiveness 
changes in job pattern 


9. 


MIS Staff Turnover Losing staff members during the 
project can cause a great deal of 
information loss to the technical 
staff. 



ERIC 



6 



Analysis Techniques 

Developing an information system requires a great deal of analytical and 
technical expertise. However, the expertise must be governed by a method which 
provides tools to clearly communicate the analysis results to the programmere 
owner and upper management when necessaiy. Characteristics required of the 
method used include: 

1. Graphical A picture paints a thousand words. 

2. Stepwise Refinement Varioas levels of detail are required. 

3. Support English Simple English explanatory text regarding application 

semantic content is easily attached. 

4. Automated It must have a computer based interface which ideally 

includes color graphic, irtelligent diagramming and 
data dictionary abilities as a minimum. 

These tools resemble the approach used by an architect designing a building. 
The architect must concisely and precisely define the specification of the building 
for a vanejy of technical experts (contractors) and the client. The drawings will Be 
at various levels of detail with each level providing an accurate analysis ofhow and 
what the end product will be like when completed. 

Analysis techniques for an automated system should try to provide three 
goals. First, the analyst should decompose and clearly understand the business 
functions to be automated. Define what the system must do or accomplish for the 
enterpnse. Don't define how it will be done procedurally until later steps. Second 
use the tools to decompose the information required to support the business 
ftinctions. Once you have identified the information define the relationships 
between the information elements to provide a relational information structure of at 
least INF and preferably 3NF. The third step is to combine the function and 
mformation into a sound procedural flow of data. 

•J ^f,y^ chosen to use a CASE tool and other support packages to 
provide mtelligent graphic diagrams with attached data dictionary support. The 
tools provide the analyst with hierarchical function decomposition diagrams, entit\ 
relationship data modeling, and Gane-Sarson Style DFD diagramming. The 
supporting tools provide a means to produce a prototype of the on-line system for 
early review of system feasibility. A walk-thru should be conducted that cballenees 
the desiMiers decisions. The analyst should be called upon to defend the design 
choices he has made. A good design will be made better and a good design w5l 
withstajid the process. When a poor solution is encountered, the walk-thru team 
niusi provide the impetus and direction to correct problems. Under no 
arcumstances should a poor solution be accepted into a new on-line system. The 
system wi 1 only get worse if you allow the orocess to produce components with 
questionable quality. 
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In summary, analysis techniques arc really quite simple. Understand the 
function, information and flow of data through the system. Build a prototype wWch 
allows your management, owner, and even departmental users to react and provide 
suggestions and/or coi^rmation to your vision of their system. It may be useful to 
thMc of this as the architect's sketches depicting the floor plan and external 
appearance of a building. His client will be able to look at his desl^ concept, 
under tand it, and then decide to accept, reject or suggest modifications to make it 
acceptable. A well conceived prototype provides a system analyst with a similar 
capaoility tor an information ^tem project. Lastly, the project manager must be 
conmiitted to a quality solution and demand that his staff provide accurate and 
complete technical implementations of the prototype. You must oemand quality in 
your system solutions. 

Communication, Training and Expectations 

Even with the best technicians available you are ensured a failed 
development project if you do not communicate and train the required audience of 
your application systenL With training the users and management will be more 
comfortable and know what to expect. To be successful, you will need to provide 
the system yc j have conditioned the users to expect. Therefore, it seems to be 
extremely prudent to manage the communication and training processes carefully. 



The communication and training process at che University of Florida is a 
three dimensional process. 

- LS. ensures that the owner understands how the application works. The 
owner/user assists actively in system testing. Qassroom sessions are 
held to train the staff of the owner area. 

- Owner manager ensures that his staff understands the new system. 
Procedures must be documented to accompany the new system 

at startup. I.S. personnel will assist the owner as needed. 

- End users at the department are trained by the owner. A set of pilot 
departments should be considered for initial startup. 

Communication and training should start early in the project's life. You 
should be persistent and deliberate, and be sure to avoid rushing through a training 
program. Finally, don't stop training after the system is operational. UF has 
systems with over 1000 department^ users. Turnover, promotions and changes in 
our staff require that we maintain an ongoing training program. Eo'^ourage 
departments to participate in the training programs and announce to users how they 
may attend a training session. Provide an easy to read and understand users' guide 
which is kept updated as system changes occar. 
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Summary 

Reviewing the strategies discussed in this document will reveal three themes 
Awarcriess of the environment and feelings that are held by the key participants of 
the project will aUow the I.S. department to approach the problems without 




Umversity commumty on the use of the application. Top management, the owner 
department, academic management and clerical staff must aU understand their role 
with the q^tem and be convinced to expect life to be better if the system is correctly 
utilized. Imonng either the political, technical or communication and training 
aspects of the system development project will make it more difficult to achieve a 
successful system. Attention given to communication, training and the project's 
nature of ongin will make a good technical solution successful. 



References : 

Blanchard, Kenneth The One Minute Man^g^r- New York: 
Berkely, 1983 

Brooks, Frederick P. The Mythical Man Month. Philippines: 
Addi son-Wesley, 1985 

Cash, James I., Jr. Corporate Intormati on Systems 
Management Text a nd Casea . Homewood, Illi-^ois: 
Irwin, 1988 

Dickson, Gary W. The Management of T nformation Systems. 
New York: McGraw-Hill, 1985 

Shneiderman, Ben Software Psycholog y. Human Factors Tg 
Computer and Information S ystems. Cambridge, Ma.: 
Withrop Publishers, 1980 



ERIC 



64 

9 



ADMINISTRATIVE AND MANAGEMENT COMPUTiNG 
. THE NEXT STEPS- 



by 



Edgar Frackmann 
HochschuMnformations-System GmbH 
Goseriede 9, Postfoch 29 20 

D-3000 Hannover 1 
Federal Republic of Germany 



Presented air .USE89 National Conference: 
"Managing Inform don Technology: Facing the Issues' 
November 28-December 1, 1989 
San Diego, California, USA 



Abstract 



During tlic present period of decentralization of administrative computing in German 
universities ^di is marl^ed by separate departmental computers and data-processing systems 
for each administrative department, some universities have started planning for the phase of 
"re-integration". Taslts to be fulfilled by more than one administrative department, cross- 
departmental data access necessities, office automation and communication, and management 
computing are the main impetus that force the universities to put the so-called re-intewation 
on their agenda. The paper describes the state of the art of administrative and management 
computing in German universities, the planning pocess for re-integration, and the esqpected 
future development r^arding the opportunities and limitations of re-integration3 
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1. Introduction 



This paper deals with the state of the art jnd future perspectives in administrative and 
management computing in German higher education institutions. To fiiJiy understand the 
organizational and implementation problems dealt with here, it should be explained tiiat most 
of the 244 higher education institutions in the Federal Republic of Germany are state funded. 
Altiiough each institution is provided with a certain autonomy it belong to one of die eleven 
states of die Federal Republic, it Li governed and administrated according to die respective 
state laws and regulations, and the role, power and functioning of die state ministry of 
higher education may be compared widi a comUnation of governing and coordinating boards 
of higher education systems in the United States. 

The paper will address three main topics. A first section is dedicated to die distinction of 
three consecutive stages of administrative and n.jnagement computing at German higher 
education institutions, a second part will focus on goals and concepts of a new era of ad- 
ministrative and management computing, and the final section describes planning and 
implementation problems, including suggestions how to resohrc thera. The paper attempts to 
address the problems in a generalizing way such as to provide valuable information beyond 
the borders of German higher education systems. 



2. The Main Stages of Administrative and Management Computing 
2.1 The *Blg System* Era 

It is interesting to remember that administrative computi- in German universities started 
with an integrated management computing approach. T^ idea in the early seventies was 
rather to buU/* die integrated Managment Information S, m (MIS) to improve planning of 
higher education dian to support die institutional administration. Although die real outcome 
of the software production efforts was not the one big integrated Managment Information 
System for state higher education policy but merely institutional administrative support 
systems with almost no integration betw een adminstrative systems exept that diey were run 
on the same mainframe, I would like to keep die term "big system era". This term might be 
justified by die fact, diat diese "bigT administrative ^tems 

were run on mainframes ("big" computers) 

claimed to support the main (big) administrative domains 

emphasized (nothing but) the (data) administration of the huge amounts nf 

that happened to occur in the higher education administration. 

These administrative domain- and th-, supporting data administration systems of this first 
phase were: The student rec. . systems including examination administration, the personnel 
and position record system, the equipment and other investment administration system, tiie 
buildings and space administration system and the stock administration system The 
accounting system remained in that first phase of adminUtrative computing in a "semi- 
automated" stage, i.e. implemented on magnetic card computers. 
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In this whole period from the late sixties to the early eighties higher education 
administrations witnessed certain developments in administrative computing with regards to 
several dimensions: the first systens startrH to be implemented and run on the (multi- 
purpose) academic computing mainframes and the later systems ended up on central 
administrative mainframes intended for jUl administrative computing systems to be 
implemented and run in one institution* The first systems of this phase of coarse were batch 
systems, and at the end of this period only dialog systems existed for admmistrative support. 
And if we regard the three groups of univcrdty staff mvolved in administrative computing, a 
shift of responsibility and closeness to computing facilities occurred within that p viod: At 
the beginning of administrative computing on the academic mainframes, the ^antral academic 
computiny staff was held fully responable for everything, the hardware, the processing of the 
software systems and even the data stored op the mainframe devices by the batch 
programmes. The administrative computing staff, continiously emer^ out of the planning 
and institutional research offices, during this period had to care increasingly about the 
hardware and software facilities, but diminishingly about the data. Whereas the Jisfiis started 
m the case of batch syt^iems with being totally scpcrated from the computing tacffities and 
ended up ^ith keyboards and screens on their desks linked to the central administrative 
computer and being fully responsible for their data and data administration. 

The software was written in CX)BOL. ISAIA or in some cases hierarchical data base systems 
used to be the data management systems. Rega^u z the whole Federal Republic a wide range 
of mainframes and operating systems were m use in the institutions. Although the systenis 
were implemented on the same one mainframe (academic mainframe in the earlier part of this 
phase and administrative mainframe later) almost no mterfaces between the systems, in the 
sense of whatever mtegration efforts, used to be implemented. 

One could coa«ider this type of computer use as a really partial support of the derk's work 
mainly and merely focusing on supporting the administration of the huge amounts of data in 
the university's administration. A certain amount of management information or rather 
statistical information was extracted from the files, hut rather on the basis of preformatted 
fixed reports, by mtermediates such as institutional researchers, and rather for the middle 
management levels or the reporting duties to be fulfilled by state mandate than for the chief 
executives. 



22 The Decentralization Era 

This era smarting about the middle of the eighties and still ongoing at most of the 
institutions is the era of the departmental computers, i.e. almost each of the university's 
administrative systems or a set of very closely related systems is implemented on a seperat 
computer. As a consequence each administrative department has its own computer or 
computers. Whereas this era started with a certain variety of operating systenss of the so- 
called mini*computers in use at the institutions, we now witness a utuation in which new 
purchases of departmental computers have ahnost exclusively the operating system MS-DOS 
for the single user PCs and the multi-user PC-networks (based on Novell), and Unix for the 
multi-user computers. 

Computers and application systems for administrative support are spreading m both directions, 
in breadth and in depth. On the one hand new areas of the central administration are about 
to involve computer systems and computer support. The *l>ig syston approach** for only large 
data set administration is no longer valuable 
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Many small systems on the margin of the big systems with even less or few data t. be 
handled were developed and implemented, such as travf I-expense-refundirg social 
admmistration, key-administraJon, room-cleaning service administration, budget planning, fund 
aUocation models, purchase o/der system, billing support system, electricity and power supply 
costing system, administration of research projects, {.lanning of the use of teaching room 
facilities. On the other hand it was a new experience for the central orgi nizers and admini- 
strative computing personnel to realize that there was an administration on decentralized 
levels such as the academic departments, academic institutes, projects and other organizatio- 
nal subumts on the academic side, sometimes doubling the central administrative efforts on a 
disaggregated level, sometimes substituting central administration. These deccntrally located 
administrations demanded their computer support as did the central administrations previously. 

h is also a phase of the conader<iUe spread of word proc -sing, now ahnost exclusively on 
PCs with one of the threr most common word processing software (Wordpc-^cct, Word, or 
Wordstar). Such organizational units with their word processing machines installed ea »er are 
now^m a process of implementing the second generation of automated word processing solely 

It is also the phase of a tremendous increase in a specific "fast" (compared wth the 
traditional "snail mail") extr A communication means: telefax 

As to the degree to which the clerk's work is supported by computers and computer systems, 
one could speak of a more comprehensive support compared with the previous phase of 
administrative somputer support. The work on keyboard and screer U less interrupted by 
papcrworl^ as more data are available electromcally and more process elements are supported 
by the software of the system applied. 

This more comprehensive support approach is due to and coupled at the same time with a 
high quality and highly user-friendly and supportive user-interface on the screens, comprising 
the following main characteristics: 

selection in menu(;s by posi»5oning of tbr cursor instead of data input 

use of function keys for every other control function 

totaliy self-explaining screens/formats 

immediate check of field input 

widely use of windows for secondary file access 

browsing in secondary files based on random access according to numerical 
identification or in alphabetic order 
reports optionally on screen or on paper. 



This user-interface is however stiU "specific". i.e. a part of the respective administrative 
"system, m contrast to standard user interfaces such as MS-Windows or GEM. 

The improved retrieval functions -nd userfriendliness are due to the fact that development 
tools, programming language and software environment of relational databases are us i (such 
as Informix with 4GL for the UNIX environment and CUpper/dBast for MS-DOS PCs) il-e 
ameliorated retrieval options also aUow direct computer outfit for management support. W- '-. 
midt fl managers such as administrative department heads indeed use the compi cr <*trectly"foif 
their information requests, chief executives still rely on intern jr ' .tcs to eet their 
mformatton. ^ 
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As in this phase of decentralization the hardware moves closely to the administrative 
departments, le. to the end users themsehes, the responsibility for everything, the hardware, 
the purchasing and processing of the software and the responsibility for the data tends to 
follow this decentralization direction as well Although central administrative computing staff 
should maintain a certain responsibility in decisions concerning the purchasing process of 
hardware and software, cocvdination, user training, and maintenance, erne witnesses with the 
rapid growth of computer use in this decentralization phase not ah^ys such an ideal sharing 
of respon^ilities between end-users and computing staff. 

23 Jbt Rc4ntcgmtion En 

After this excessive spread of staiid-alone computers all over the central and deccntral 
administration it is nothing but a logical step that a re-integration should take plac;. 
Although this phase is nowhere fully implemented but rather in its conceptional and puinniag 
phase, one can conceive the main traits and rationales of this phase: 

There are certain administrative tasks that are fiilfilled not only by one clerk at one 
desk, but are to be handed over from one desk to another until completed. A purchase 
order from the central purcL.-'*mg department, e.g., is followed by an input into the 
central accounting system. An ii>put in decentral accounts, eg., should be followed by 
an entry mio the central accounting system (on an aggregated level). An integration 
with respect to the different computer systems according to the need of the 
administrative processes could be reached by two alternatives: by direct upda ^ or by 
file transfer. 

The passing over of data out of the administrative file, to text flies for word 
processing purposes is ano^Jier issue of re-integration. 

University internal communication such as Message Handling Systems (MHS) require 
integration in the form of networks. 

There is a need for at least read-only access to central files inside the university, from 
various decentral places and po^ons. 

Statistics, reports and management information often have to rely on more than one 
administrative system and file in order to integrate this information I 3 one report. 
The use of central resources such as high speed laser printers, central back-up storage, 
access to external tele-communication services (X2S) and external information services 
from more than only one terminal in the institution demand integration of single or 
multi-user places. 

Telefax and analog telefon is a non-integrative form of external communication. One 
could easily predict that telefax in the future vnH be succeeded by teletex as the most 
used form of teleiommuni^tion, apart from telefon. 

The multi-functional ttc^^inal and a common user-interface controlling whatever 
application from word processing to administrative systems at the individual working 
place from the clerk to the chief executive is another facette of integration. 

In contrast to the decentralization era, where we were talking of a rather comprehensive 
support of the deck's work by computer systems, this era might be characterized by a quasi 
total and integrated support with almost no *paner-based* interrupts in the clerks' 
administrative pr< messes at the keyboards and screens. 1 will also be the phase of executive 
support systems with executives' direct access to and *han js-on* desk-top keyboards, mice, 
screens etc 
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If the central administrative computing staff docs not take over the full responsibility for 
administrative computing in the central and dcccntral offices yet in the stage of concepts 
and planning, re-integration with all the benefits expected will never become reality. 



3. Goals and Concepts for the Next Step of AdmlnlstniUvc and Management Computing 
3.1 Strategic Relevance of AdmlDlstrativc and Management Computing 

The next steps arc, of course, depending on the actual stage in the respective institution, 
both the decentralized spread of single purpose computers and the re-integration of tficse 
seperated facilities. But it is rather the integration-phase, needing planning, 
conceptualization, in contrast to tiie incremental growth of tiie decentralization phase. And it 
is also the re-integration phase, giving rise to morr general thoughts on goals, objectives 
and general benefits and the strategic meaning of administrative and management computing. 
The question might also be posed as to M^etiier and how university administrative and mana- 
gement computing differ significantiy from the corporate world and its computing services. 
There are four aspects to be considered: 

(1) Tlie •service* aspect: Whereas administrttive computing in tiie corporate world, ecpedally 
in industry might »>n fully integrated into concepts of CIM or P?S, and thus serving tiie 
clients of the organization as well as internally, in tiie university administrative womputmg is 
almost totally seperated from tiie primary production processes and customer services. Thus 
the university administration and administrative computing is not directiy linked to the aim 
of serving the university clients, bnt rather the members of the university prod action 
processes inside tiie institution of whom, of course, the students are botii customers and 
producers. But tiie better, the faster, and the less bureaucratic the central or c^central 
administration might function, due to the computer system support (but also due to the 
behaviour, effidenqr and effectiveness of tiie administration employees), tiie more tiie overall 
atmosphere, functioning, effectiveness, productivity and creativity of tiie univcrsit/s primary 
produc. rs and production processes might be enhanced. Administrative con- lUting - on 
whatever developmental stage - should primarily help the administrative employees do their 
jobs better, and in tiie integration phase to get tiie decision makers more involved into tiie 
benefits of adminis. >tive computing by improved and direct infoimation retrieval options. 

(2) The "Leading Edge of Technology* asptct: Taking into account the research and 
development functions of the universities, it would fit very well into the "image" of the 
individual institution to provide its own administration with tiie leadmg edge of the techno- 
logy equipment and systems, even compared mih the corporate world. But one has to be 
careful not to get confused about tiie size of tiie "enterprise" un' jjrsity. The higher educa- 
tion institution has to be compared witii small to middle sized corporate enlerpriscs. It was 
e.g. a mistake, as far as we can judge, to base administrative computing in the phase of the 
mainframe computers on data base software such as IMS, UDS and ADABAS. It would have 
been better to stick to the ISAM data management, in order to "consume" less computer 
resources compared witii tiie data to be administred and compared with the retrieval needed 
at that time. But nevertheless it would suit the higher education institutions very well to 
have tiie 'wading edge of tiic techndogy implemented in tiieir tdministrations, compared witii 
the "right size" corporate enterprises. 

(3) The *informaition" aspect: European higher education institutions have reccntiy tended to 
be more e^qposed to a competitive "market" of higher education and research. 
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The more autonomy th^ are granted in that sense and the more they have to care about 
their strategic uniqueness and their market niche, the more their challenges are converging 
to those of the corporate enterprises. Executive managegemtnt information, especially for the 
manag^T3 on the academic side of the enterprise university (President, Vice-Presidents, 
Deans) gains increasingly in having a strategic relevance, llie information domains focus not 
only on the resources, processes and performances of the institution, but on various aspects 
of the institution's environment. 

(4) The "implementation" aspect. University administration in Europe has more in common 
with public administration than with business administration. Althoi^ public administrations 
often show in their organizational structures quite a lot of hierarchical levels, the daily work 
and administrative processes of the subordinates seem rather to be shaped by laws and fixed 
regulations than by the giudance of the respective leadership-level persons. As a consequence 
often subordinate clerks have more influence on the implementation of computer support than 
the respective leaders of the administrative department or than the chief administrator. 
Although this might be beneficial for the motivation of the clerks it bears the dangpr of 
perpetuating organizational structuies and impeding strategic decisions as regards the 
university administration, strategic decisions that could be made in the course of computer 
support implementation. 

32 Premises, "oals, Objectives, und Concepts for the Next Steps of Administrative and 
Management Computing 

It should be stressed once more that the next step of administrative and management 
computing in higher education is both a continuation of the decentralization together with 
the spread of departmental computers and systems, and the re-integrat on based on computer 
networks. 

The premises, goals, and objectives of the next step arc stated rather similarily by ail 
institutions that are going to work out concepts, as foUows: 

The concept of the central administrative computer should be aHolished as far as 
possible. Departmental computers should be the prevailing concept of administrative 
computing. 

All levels of the universtt/s administrat. jn shoulc' be supported by computers and 
systems. The amount of data to be stored and handled is no longer i criteria for 
automation. 

Access to data and the general user-interface should be highly comfortable. 

Access to "centra!" files (Le. to departmental computer systems in die central university 
administration) should be provided for those who need this information for 
administrative or deoMon making purposes. 

Whatever transfer of data and documents is necessary inside the institution, it should bo 
handled electronically and not by paper-documents. Data-input should not be necessary 
more than once in the flow of the administrative process. 

The primary goal of the so-called office automation is to implement word processing 
everywhere from the scientist to the seaetary. 
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Message handling (MHS) seems not to have (the highest priority inside and between 
German higher education bstitutions. 

There is an increasing demand for better, faster and desk-top information for all levck 
of university management, now for the chief executives as wclL 

Data security and privacy as regards personnel data (student record files and personnel 
records) seem to have a very high priority with severe consequences for all concepts of 
networks and access tc data. Administrative and statistic data have to be seperated from 
each other. Academic and administrative computing stringently seperated. 

These premises, goals and objectives lead to some common traits of the concepts that have 
recently been developed at various institutions: 

Administrative departments are to be supplied with their own computer to run only the 
one system or the set of very dcscly related applications for this department. There are 
indeed four models for the departmental computer conftguratwn, usually mentioned in 
the plans and concepts: (1) The MS-DOS PC with CUpper/dBasc or Informix as relational 
database systems for those applications with only one user and rather limited data sets 
to be adminstred. It is also the typical configuration for the nt^hcr small decentralized 
adn^inistration in the academic departments, in academic institutes or in the research 
projects with their own administrations. (2) The second model is the Unix-computer for 
those applications and administrative departments with more than one user at a time. 
The relational database and the programmmg language used are Informix and 4GL. (3) 
The third model, being ;ust an alternative for the same multi-user constellation consists 
of a PC-network, using NoveU as network software and having a central file- and 
network-server (386-PC). (4) The fourth model consists of a combination of both, the 
Unix computer with PCs instead of non-mtelligent terminals, and the underlying reason 
for this model is a combination of central and decentral computing at the individual 
working place. 

Data and document transfer befveen administrative departments and systems in the 
course of admmistrative task fulfiknent should no longer be handled on paper basis but 
rather electronicaUy. Although direct update from one systen^. to another department's 
system would be imaginable, file transfer with subsequent update by the clerk 
responsible for the receiving system, is the favoured model according to the present 
concepts. 

To handle the daia communication and transfer of data and documents between the 
seperated administrative computers and applications online, an admmstrative network is 
being planned. This network usually has two components or units: the central university' 
administration and the decentral administration m the academic departments. 

Because of the extraordmaiy high security, privacy and confidentiallity requirements the 
academic and the administrative network are thought to be seperated physically ahnost 
totally. In fact there are four ''uasi seperated 'planning units* as regards computer 
support and networking in German hi^r education institutions with only few overlap: 
the central administration, the decentral academic administration, the academic 
computing, and the library mdudkig access to external data bases. The main mterfrice 
necessary for all four units is the access to external communication facilities: the 
German Academic Network (DFN) indudmg all X2S facilities. 

7 



ERIC 



73 



330 



The fact that there is only little overlap is due rather to the security and privacy 
requirements (especially witt regards to student and pe*^ onnel data) than to other 
reasons based on the working processes. In case the <«cademics need access to 
administrative or statistical data they have to use the academic administration terminals 
with their access to central information files instead of academic computing fadlities. 

Even the link between the decentral academic and the central university administration 
is thought to be somewhat "buffered* for the same security and privaqr reasons: three 
alternatives are to be found in the university concepts: (1) If direct access to the 
administrative computer and files is planned to be allowed at all, it is a lead-only 
access, using the retrieval programmes provided on the administrative computer, and 
documenting every successhd and unsuccessful attempt at access to data. Whenever 
update in central administrative files is necessary it wiU be handled throu^ file trans- 
fer, the transferred files being used for update by the central administration clerks 
themselves. (2) Information retrieval according to the second even more "secure" alter- 
native takes place on seperate information files to be mamtained on seperate computers 
in the network and to be fed periodically fiom the administrative systems. (3) The most 
consistent "buffering" alternative is a requester/server or mailbox-concept, i^ere the 
decentral requesters formulate their information retrieval requirements through a 
message handling system into a central mailbox, and central administration clerks answer 
the request by means of e-mail after having looked into the!r mailbox. 

Both for security reasons and for the reason of user-friendly and easy-to-handlc user 
interfaces, the concepts pro^de for or even mandate the "hidingf and "lockingf of the 
operating system and its operations against direct user interference. In the case of 
single user PCs often security software such as Safeguard are declared mandatory. The 
most advanced concepts even think about common user interfaces to take over the 
control for all applications or even sub-functions of applications on one terminal at one 
working place. Unix computers Uniplex and Q-OfGce are examples to be investigated 
in further detail 

The re-integration phase seems to provide the maturity of computer-technology for 
direct executive support. The more advanced concepts contain special sub-networks 
linking at least the Prradent, the Vice-Presidents, the Chief Administrative Officer, and 
the institutional research and planning office together, with nodes consisting of MS-DOS 
PCs or Maclntoshs, the latter using new user interface concepts such as HyperCard. The 
primary goal of executive support seems however not to be communication on the base 
of a message handling system, but rather direct executive access to information. The 
following information elements are planned to be implemented and maintained (the 
maintenance being the mo t crucial and sensitive parameter in this kind of executive 
support systems): 

"self-discriptive** data with respect to the individual institution 

non-numeric, verbal information on the individual institution (role and mission 

statements, central and important decisions etc) 

inter-institutkonal comparative data on critical success factor areas 

general higher education related data, describing the relevant environment of the 

institution (highly aggregated statistical data, economic data, demographic data 

etc) 
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non-numeric, verbal information of importance for the institutional policy and 
decision making (such as statements of legislators and politicians, information on 
federal and state financial programmes and initiatives, definitions of data elements 
etc). 



4. Problems of Planning and Implementation of AdministniUyc and Management Computing 



The following section is based on the experiences in the "big system** and the 
"decentralization" phase and is extrapolated into the phase of "re-integration" with its 
specific characteristics. It is also an attempt to find answers and solutions to problems diat 
emerged during planning and implementation processes. 

4.1 Comprehensive Planning or Incrementalism 

Comprehensive planning in the past turned cut to impede rather than to facilitate quick 
responses to computer service need in the university administration and to technological 
opportunities. The technological development and prices of computer hardware are changing 
so rapidly that plans tend to become obsolete at best soon after their completion. A 
thoroughly and comprehensivley conducted analysis of word processing need of a whole 
university m 1984, e.g., ended up wth the recommendation to install at most of the word 
processing places electronic typewriting machines (with one line displays and small memories), 
whereas today ?-86-PCs and laser printers at places wth intensive word procesdng activities 
seem to be thc^ common standard. The coordi^^^tion fiiaction of central university wide plans 
with regards to the variety of computer hardware and software (including administrative 
applications as wcU as word processing) on the campus can be achieved more "silently" and 
indirectly by offering centra! services for niily selected hard ware and i^nftwar^ on the 
campus, such as training for users, maintenance, consulting and "trouble shooting hot Imes. 
Today one should really count on the normative and standardizing forces of the so-called 
"industry standards" and standard software availaUe m the MS-DOS and Unix environment 
Networking, of course, needs someindiat more planning, but one should not hesitate to plan 
for and implement sub-networks, which even take better account of security and privacy 
aspects than comprehensive administrative or campus-wide networks. 

42 State-wide (System-wide) Co-erdlnatlon 

There are some states in the Federal Republic of Germany with rather extensive state-wide 
coordination mech^iisms concerning ahnost all university administrative computmg items, with 
the aim of unification and for economic reasons. One stringent means of state coordination is 
a central state budget for all administrative computing purchases and decisions to be made 
centrally m coordinating committees on the state level. There is one laajor advantage to be 
emphasized with regards to this central cjordinating model: It assists the university 
administrations to survive the competition with the academic computing mvestments, which 
often would leave only very small "budget bits" for idministrative computing facilities. State 
central re^x>mmendations, decisions and budgets may back the technological advancement of 
ac muiistrative computing. But the disadvantages seem to overshadow the advantages of state 
central decision makmg committees: Those university administrations or administrative 
departments ^ch do not really want administrate /e computin;^ facilities may easily hide 
their reluctance behind the long lasting coordinating processes, ,Aile these processes at the 
same time tend to impede a quick decision for thoy; administrations which urgently need and 
would like to implement computing support. 



Coordinating and decsion making comnsittees tend to require each PC to be decided upon in 
the central committee meetings! 



43 Academic and Adminbtrmtiyc Computing Relationships 

Most institutions have their' Academic senate conunittee to dedde upon the big investments, 
regardless Aether academic or administrative support is under review. Especially m the *l)ig 
system* phase of administrative computing this dedsion maldn^ structure as a result treated 
the university's adminbtration as as ^stepchild" vnth regards to computer fadlity investment 
One solution would be to decentralize decision making on computer facilities by 
decentralizing budgets. But again the budgets for administrative computing mi^ be limited 
too much in favour of academic computing budgets. The best solution is, of course, an 
enhanr^4 visibility of administrative computing services for the academics, i.e. quick and 
direct online access to data they mJ^t need for their administrative, teaching and research 
activities. This kind of 'involvemc of academics in administrative computing outcomes 
indeed showed less reluctance towards administrative computing investments in recent dedson 
making processes. Compromises have to be found between high standards of security and 
privacy protection on the one hand and qidck and easy*to-liandle retrieval facilities for the 
academic side. 



4.4 The Role of the End-User 

As stated earlier the final end-user of public administrations including the university ad- 
ministration is rather powerful as to the organization of his/her work and administrative 
processes. This power extends to the formulation of requirements towards the data processing 
systems' developers and the implementation and processing of these systems. It does often, 
especially in the case of big administrative departments, not suffice, to have only <me person 
resoonsible for the deGnitiou of user requirements towards the system developers, one person 
who rather tends to become a data processing expert than to remain the advocat of the 
user -requirements. Rather especially in the implementation phase, one should build on 
''concentric circles* aro. jd those users who show special identification with the new 
technology, who received special training, and who could help guu-antee the motivation and 
immediate problem solving more than any other more centralized orgamzation of user support. 

There is however the danger that the relative power of the administrative end-user teads to 
a perpetuation the way ir which administrative tasks are ftdfiUed. End users might tend to 
formidate requirements toi automation such as not to change the flow of processes at all. 
Unless one does not succeed in involving the leaders in this process and build on their 
responsibility for the overall efficiency of univer^ administratiou, the benefits of computer 
technology for the administraiion wiO not be fiilly appreciated and used« The involvement of 
the Chief Administrator of the institution and of the President in the hard- and software 
implementation decisions and processes seem to be crucial, especially m the phase of re- 
integration, where things can really be changed. 

4.5 Responsibility of the Central Administniti\Y Compnting Staff 

As ever m organizations the motivation of the individual is more crucial (or the ftdfilment of 
the organization's functions than formal structures and responsibifities. 
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In the phase of decentralization it was indeed an undoubtable experience, that those 
implementations of administrative systems worked best, v/huc tbs end users felt responsible 
for everything, from requrirements analysis to the daUy running of the departmental computer 
and the daily back-up of the modified departmental data files. This "informal" or non- 
formalized responsibility cannot however serve as the model for administrative computing 
organization, especially in the case of network facilities existing in the university 
administration. There should be a stable and secure responsibility at a university central 
administrative staff level for the maintenance of hardware and software of the decentralized 
computers as well as for the network, training, immediate trouble shooting, further 
developments of software especially to serve additional retrieval requirements. There is 
however a shift in the activities of these staff members to be perceived from daUy running 
of the administrative systems to more long term activities and ad hoc bvolvement in 
exceptional situations in the course of the daily running of the computer systems. 



4.6 Self-made or Purchased Standard Software 

Several reasons in German higher educition administrations suggest the p/eference for 
standard software for administrative support. Institutions usually have not enough 
administrative computing staff in order to do both maintaining existing software and 
developing new software systems for the admbistration. To have students of computer science 
or business administration programmes develope systems in »he context of courses or 
examinations, did not proove a valuable approach. The use of methods, tools and principles is 
more important for the students' learning process than the immediate result f - the 
university administration, and there is a lack of continuity in the maintenance of J zsc 
"academidy" self-made systems. 

Due to common laws and regulations, some of them even on the federal level, others at least 
on the state level, and being applied mandatorily by ali institutions in one state, the 
ttr ilementation of "standard systems" seems to be pos^ble. These "standard systems" provide 
at "cast support for the so-called core functions of the administrative processes in the 
insu utions. With the ceutral administrative computing staff remains however the task to do 
the adjustments (especially additional and special retrieval functions) at the margm of the 
core systems. 



4.7 Laws and ReguiatIok.s 

The often most influencial laws as regards the planning end implementation pre .ss of 
computer support in university administrations seem to be the law to garantee formal 
participation (co-determination act) and the law garanteeing privacy and protection of 
personnel daU. There is no other solution for the success of the system implementation as to 
mvohre those being the formal representatives of participation and data proT'-iion as early as 
possible in the process of planning and implementation. If the final end-users are really 
convinced about the benefits of the new systems then there is no reason for those formal 
representatives, who rather tend to defer or even to impede computer support implementation, 
to oppose hcavUy. Severe data protection and privacy laws impact the decoupling principles 
and mechanisms between administrative support and retrieval functions for others than 
central administrators, that have been des:ribed earlier in this paper in the context of 
university wide networks. 
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4A Uaiversity Managoncnt and Adini'-isUiitiv^ Computing 



University Management, be it the middle management level of administrative department 
heads, the Chief Administrative Officer or the President have not been involved enough L*" 
administrative computing decisions in the pa" i Administrative computing can however benefit 
greatly and evci receive its major incentives from management requirements. Its early 
attempts owes administrative computing to the management information requirements (compare 
the MIS approach in the late sixties and early seventies which marks the birth of 
administrative computing in German higher education institutions, which was however more 
directed towards state and federal state level management information than towards the 
support of institutional management). 

University Management involvement m administrative computing planning and implementation 
seems to be crucial, in order: 

to overcome the perpetuation of once existing administrative Sixuctures and to fully use 
the efifidenc^ potentials of computer technology 

to fully set to work the strategic importance of administrative computing 

to fiilly use the potential of present computer technology with regards to executive 

support. 

The development and use of executive sup;x>rt systems by the executives themse^es may not 
only impact their involvement in admiiTistrative computing issues but may also shape 
decisively the administrative support systcus \^ch then wiU have an additional function to 
supply executive support systems with aggregated data automaticallly and periodically. 



5. Conclusions 

German higher education administrative computmg has undergone and is still in the process 
of a "dramatic" decentralization of computer hardware and software implementation and use, 
with the prevailing concept of seperate departmental computers. The main emphasis of this 
phase of administrative computing support was laid on very high standards of the mdividual 
clerk's work support and on very user-friendly and easy-to-handle user-interfaces. The next 
step, a re-integration of the seperated computer and system facilities, mil help reduce the 
paper-based interrupts and data mput with regards to the clerk's work. 

But perhaps the even more important benefits of this next step of administrative and 
management computing vnH be the direct recess to data and information by thos* in some 
distancr^ from the daily administrative processes, i.e by the institutional managers. The 
executive support system pers seems to be the a^^ost interesting perspective of this 

future era. 



12 

7S 



